439
edits
(2 intermediate revisions by the same user not shown) | |||
Line 19: | Line 19: | ||
=== How we initially intended to solve these problems === | === How we initially intended to solve these problems === | ||
We intended to go to a single user/machine configuration for most applications and libraries, where all applications open the same set of databases for a particular user and machine. This configuration would not be in any one application's specific directory of application configuration files, but would be part of the system. One problem with this approach is that not all NSS applications run on systems which will have a 'system configured' NSS. In addition, there are still cases where the user may want to keep multiple different configurations for testing (Mozilla profiles for example). Finally, some | We intended to go to a single user/machine configuration for most applications and libraries, where all applications open the same set of databases for a particular user and machine. This configuration would not be in any one application's specific directory of application configuration files, but would be part of the system. One problem with this approach is that not all NSS applications run on systems which will have a 'system configured' NSS. In addition, there are still cases where the user may want to keep multiple different configurations for testing (Mozilla profiles for example). Finally, some users only need read-only access to the NSS configuration, but other users (like Firefox, or Thunderbird) need read-write access. This means if a read/only library initializes first, then a read/write application in that same address space will not be able to update the database. (what?? --[[User:Nelsonb|MisterTLS]] 21:48, 1 September 2009 (UTC) I've changed application->library. This is a real issue that I believe sun reported. PAM calls pam-ldap which initializes NSS read only. now FF and TB can't get to their databases.) | ||
=== Restrictions on any future solution === | === Restrictions on any future solution === | ||
Line 27: | Line 27: | ||
The existing shutdown will close down all NSS internal references to object and free up internal lists. It is possible that the application may still hold references to NSS objects (such as slots, keys, or certs that NSS has returned to it) in its address space. NSS will shutdown all slots that do not have outstanding object references to them. If NSS cannot shutdown all slots, it will return an error. At this point NSS is 'shutdown', but it will not be able to initialized again until all those outstanding references are freed. | The existing shutdown will close down all NSS internal references to object and free up internal lists. It is possible that the application may still hold references to NSS objects (such as slots, keys, or certs that NSS has returned to it) in its address space. NSS will shutdown all slots that do not have outstanding object references to them. If NSS cannot shutdown all slots, it will return an error. At this point NSS is 'shutdown', but it will not be able to initialized again until all those outstanding references are freed. | ||
Few applications depend on | Few applications depend on being able to shutdown with a single NSS_Shutdown call, but there are some that do, usually applications which have some sort of dynamic profile switching code. Even though these apps are few, they must still continue to work.(Do you mean continue to fail? --[[User:Nelsonb|MisterTLS]] 21:48, 1 September 2009 (UTC) no, I mean continue to work. Applications that call the base NSS_InitXXX expect it to be idempotent. It will continue to be. Applications expect to call NSS_Shutdown() and be able to switch profiles. This will continue to work as well. This last one we can discuss. It may make more sense for NSS_Shutdown to work as NSS_ShutdownContext(NULL) does. ) Caveat: Note that today, if there is a library using NSS and holding references, such profile switching will not work in any of the scenarios. | ||
2) '''NSS still maintains a single 'trust domain' in which certificates are verified.''' In a single process, NSS has the ability to process certificates in the context of any one of several independent trust domains, but many of NSS's existing API functions do not allow a trust domain to be explicitly specified. | 2) '''NSS still maintains a single 'trust domain' in which certificates are verified.''' In a single process, NSS has the ability to process certificates in the context of any one of several independent trust domains, but many of NSS's existing API functions do not allow a trust domain to be explicitly specified. |
edits