14
edits
NSS Shared DB And LINUX: Difference between revisions
→Type 1 packages: User applications
Wrosenauer (talk | contribs) (removed hint about NSS_InitWithMerge bug) |
|||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 37: | Line 37: | ||
How this happens will be explained later, but first we discuss where the requirements for the above come from. | How this happens will be explained later, but first we discuss where the requirements for the above come from. | ||
[#1 is alarming, and looks like black magic. Why, when I tell the API to look in /etc/pki, should I expect it to look anywhere else?] | [#1 is alarming, and looks like black magic. Why, when I tell the API to look in /etc/pki, should I expect it to look anywhere else? This always happens, /etc/pki/nssdb has a file called pkcs11.txt that loads all the databases/modules related to opening that directory. The change here is softoken can now automatically open more then one itself.] | ||
= Requirements by Package Type = | = Requirements by Package Type = | ||
| Line 53: | Line 53: | ||
User applications should open NSS using a shared database stored in ~/.pki/nssdb in the user's home directory. If the application needs to store new certificates (like a web browser), then it should open this database read/write. User's local preferences would be stored in this database. Changes the application wants to make will occur in this database. Any user specified tokens would also be stored in this database. | User applications should open NSS using a shared database stored in ~/.pki/nssdb in the user's home directory. If the application needs to store new certificates (like a web browser), then it should open this database read/write. User's local preferences would be stored in this database. Changes the application wants to make will occur in this database. Any user specified tokens would also be stored in this database. | ||
In addition, the application should | In addition, the application should open the system database /etc/pki/nssdb. This database should be opened read only. The user will typically not have permission to modify this database. This database will provide system level defaults for tokens to load and root certs to trust. This gives us hooks form things like IPA to manage and distribute trusted root certs system wide. | ||
[I'm almost certain there's a typo there - how can every application *own* the system database? Don't you mean *open*?] | [I'm almost certain there's a typo there - how can every application *own* the system database? Don't you mean *open*? - bob: you are correct, changed.] | ||
[How does an application open first the user database at ~/.pki/nssdb, with NSS_InitReadWrite I presume, and then opens the system database in /etc/pki/nssdb? Since the NSS intialization calls are idempotent, does it need to use NSS_InitContext to accomplish this?] | |||
== Type 2 packages: Services applications == | == Type 2 packages: Services applications == | ||
| Line 65: | Line 67: | ||
Option 3: Either option 1 or option 2 except the 'user' database for the server isn't necessarily stored in ~/.pki/{server_user}, but is configurable for each server. | Option 3: Either option 1 or option 2 except the 'user' database for the server isn't necessarily stored in ~/.pki/{server_user}, but is configurable for each server. | ||
[Option 1 certainly makes the least sense. The point behind PK crypto is that public keys can be public and private keys must be private. Storing every services' private keys in a shared DB that everyone has equal access to seems counterproductive.] | [Option 1 certainly makes the least sense. The point behind PK crypto is that public keys can be public and private keys must be private. Storing every services' private keys in a shared DB that everyone has equal access to seems counterproductive. - bob: agree, it's probably a bad idea to put key material in /etc/pki/nssdb for more than one reason, though it may make sense for servers to have a shared key store (between other servers) along with a private one.] | ||
== Type 3 packages: Libraries == | == Type 3 packages: Libraries == | ||
| Line 71: | Line 73: | ||
Type 3 packages should open ~/.pki/nssdb and /etc/pki/nssdb read only. If the packages are stand alone, this should be sufficient. If the packages are part of a bigger application, then it should follow the needs of that bigger application. | Type 3 packages should open ~/.pki/nssdb and /etc/pki/nssdb read only. If the packages are stand alone, this should be sufficient. If the packages are part of a bigger application, then it should follow the needs of that bigger application. | ||
[Is the order of initialization important? What happens when the library opens things read-only, but it's linked into an application that wants read-write access? What happens when the lib is init'd first? What happens when the app inits NSS first?] | [Is the order of initialization important? order only has a tangential effect (what slot the DB's wind up in. What happens when the library opens things read-only, but it's linked into an application that wants read-write access? What happens when the lib is init'd first? What happens when the app inits NSS first? Most of these issues are handled in the multi init call, but the short answer is if a database is opened ro and it needs to be opened r/w, we will open the database again, r/w] | ||
== Summary of Requirements == | == Summary of Requirements == | ||
| Line 122: | Line 124: | ||
* in the old dbm days, secmod.db was combined in the softoken PKCS #11 module primarily because that's where the dbm code was. With the sql database, it's possible to separate the moduleDB load from softoken. That might be a good plan for 3.13, removing yet more code from the cryptographic boundary of NSS. | * in the old dbm days, secmod.db was combined in the softoken PKCS #11 module primarily because that's where the dbm code was. With the sql database, it's possible to separate the moduleDB load from softoken. That might be a good plan for 3.13, removing yet more code from the cryptographic boundary of NSS. | ||
* IMO, hardcoding magic behavior like this (open two locations when only one path was passed into the API) is a mistake. It's obvious that /etc/pki/nssdb is "special" and the API ought to highlight this fact. There should be a distinct API call for initializing the system default location, separate from the call for accessing a user-specified configuration, and every app/caller that needs instance-specific configuration should explicitly call both APIs. | * IMO, hardcoding magic behavior like this (open two locations when only one path was passed into the API) is a mistake. It's obvious that /etc/pki/nssdb is "special" and the API ought to highlight this fact. There should be a distinct API call for initializing the system default location, separate from the call for accessing a user-specified configuration, and every app/caller that needs instance-specific configuration should explicitly call both APIs. | ||
**[bob:It's only special because the 'system' configured it to be special. I can set *any* directory up to do exactly this without change to NSS. What's important is it's a single roundevous point. If your app has a config file that selects the NSS database, you can force that app into the new scheme by adding sql:/etc/pki/nssdb in that config file. NOTE: you will not find the string /etc/pki/nssdb anywhere inside NSS itself] | |||
The overall feel I get from reading this page is still that NSS was designed for single-user client usage, and server/library usage are a hasty afterthought. The only way to get away from the NSS_Shutdown problem is by introducing new APIs that are specifically designed for these new use cases, and punting backward compatibility. (I.e., stability of apps that only use the existing APIs cannot be guaranteed in this new environment.) | *The overall feel I get from reading this page is still that NSS was designed for single-user client usage, and server/library usage are a hasty afterthought. The only way to get away from the NSS_Shutdown problem is by introducing new APIs that are specifically designed for these new use cases, and punting backward compatibility. (I.e., stability of apps that only use the existing APIs cannot be guaranteed in this new environment.) | ||
[bob: This is not supposed to address *that* issue. The idea here is that control of what gets opened or not now rests with the OS (under administrator control). Many of the issues you were looking for are in the multinit proposal] | |||
E.g.: use a distinct API call to initialize the default /etc/pki/nssdb database. Refcount all DB opens. Use a distinct API call to close each database, instead of a one-call-destroys-everything Shutdown. Use an atexit() or similar destructor to make sure that Shutdown on hardware tokens occurs if an app exits without cleaning up nicely. (You're still SOL if you get SIGKILL but you always were...) | E.g.: use a distinct API call to initialize the default /etc/pki/nssdb database. Refcount all DB opens. Use a distinct API call to close each database, instead of a one-call-destroys-everything Shutdown. Use an atexit() or similar destructor to make sure that Shutdown on hardware tokens occurs if an app exits without cleaning up nicely. (You're still SOL if you get SIGKILL but you always were...) | ||
[bob: several of these are in the multi init proposal] [[NSS_Library_Init|here]] | |||