As of today, if using NSS initialize, on a non-existing directory provided as a database path, NSS will fail with an error like "bad database". The proposal is that NSS creates the missing directories as necessary, with multiple levels. Any objections?
I can't help feeling a bit nervous with the idea of creating the directory the whole slew of paths to it. A more conservative approach would to do parameter validation and let the user know that the directory doesn't exist. Bug 325376 is related to this one and attached is a first cut of a patch for non-existing directory validation and error reporting.
I'd agree with Elio - creating paths automatically leaves me a bit uneasy, especially for code that may run with elevated privileges (eg: on servers) Validating the parameters as Elio proposes does sound like a better way to be improve the user & developer experience.
I also agree with Elio and Ryan. Besides their concerns, I would add that it is difficult to ensure that all NSS-based apps could agree on what the file permissions for the directories should be.
If we need this functionality, we should have a helper call which we call before NSS_Initialize(). To add yet another reason to counter this, NSS itself doesn't open any of the databases, softoken does. I really don't think softoken should be silently creating directories on the fly. It seems fraught with problems. A helper function in NSS Util would be fine, but I don't think every application wants this auto-create behaviour (the vast majority of NSS applications actually opens the databases read-only!). bob
I heard your arguments and they are reasonable. The original proposal is hereby rejected. But I wonder if we could have a special handling, if an application requests to use the default location for the user's shared database. The intention is to encourage (future new) applications to use this default path, and make it simpler for them to startup NSS. We could #define a "default" value for the path parameter, e.g.: #define NSS_DEFAULT_USER_DB_PATH "some-special-value-string" If NSS db init path == this special string, it would instruct NSS to use $HOME/.pki/nssdb on Linux/Unix/OSX, and if necessary, create the missing directory. For any other path value, NSS would continue to never create directories. Would this make sense?
Severity: normal → enhancement
Summary: On init, NSS should create the directories to the database path → Simplify NSS init with a "default user shared db" path identifier and automatically create the directory
Whiteboard: [new summary comment 6]
Version: 3.14 → trunk
(In reply to Kai Engert (:kaie) from comment #6) > I heard your arguments and they are reasonable. > The original proposal is hereby rejected. > > But I wonder if we could have a special handling, if an application requests > to use the default location for the user's shared database. This is especially relevant when loading libsoftkn3.so as a PKCS#11 module, like the seahorse certificate manager does. > The intention is to encourage (future new) applications to use this default > path, and make it simpler for them to startup NSS. > > We could #define a "default" value for the path parameter, e.g.: > > #define NSS_DEFAULT_USER_DB_PATH "some-special-value-string" Could the parameter be another form of 'configdir' parameter used in the NSS init string? That may be what you're suggesting, and I'm showing my newbness here :) But currently we use configdir='sql:$HOME/.pki/nssdb' in the init string to load the shared user database (obviously with $HOME subbed). Could it be perhaps something like: configdir='default:user-shared'
Stef, there are several variations of calls to initialize NSS. Besides the fully flexible variant that requires you to provide a complex string, there are also simpler variations that only take a directory and some flags. For example, Firefox does: uint32_t init_flags = NSS_INIT_NOROOTINIT | NSS_INIT_OPTIMIZESPACE; SECStatus init_rv = ::NSS_Initialize(profileStr.get(), "", "", SECMOD_DB, init_flags); So to clarify, my proposal is to use a string value for the directory, that would be acceptable in both API variations. Keeping with Stef's example, it could be: #define NSS_DEFAULT_USER_DB_PATH "default:user-shared"
I like "default:user-shared". I've been meaning to propose a special string for /etc/pki/nssdb, so that applications don't need to know about that. (Not all Linux distributions have /etc/pki/nssdb.) "default:user-shared" can point to either $HOME/.pki/nssdb or /etc/pki/nssdb internally, depending on the system NSS library in the Linux distribution.
You need to log in before you can comment on or make changes to this bug.