On 03/21/2017 02:26 PM, Rob Crittenden wrote:
Um, this _might_ work. Each httpd worker will have an fd open to the NSS
database files so you'd want to do this rather carefully.

I'm no expert on this stuff, but my understanding is that any file
descriptors will continue to point to the older database files until a
worker is restarted or it closes and reopens a file for some reason
(which I have no reason to believe mod_nss does).

Even if a worker does do this for some reason, the /etc/httpd/alias
symlink can be changed atomically, so it will only be an issue if a
worker reopens an NSS database at the same time that the symlink is
being updated -- thus getting inconsistent versions of secmod.db,
cert8.db, or key3.db.  If this happens, NSS will presumably return
SEC_ERROR_ALIENS_ATTACKING, or something similarly inaccurate and non-

(Even this wouldn't be an issue if NSS used openat() like a library that
actually cares about ... security, but I digress.)

In order for NSS to see a newly added certificate it will need to reopen
the database. I'm fairly certain a SIGHUP will cause all the children to
be respawned so except for those actually serving a request at the time
the new certs should be available.

I'll check on SIGHUP.  Even if it doesn't work, a complete restart is
much easier to coordinate than shutting down Apache, updating the
database, and restarting it.

Ian Pilcher                                         arequip...@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to