Bug 132608 - glibc: RFE: NSS auto-reload nsswitch.conf
Summary: glibc: RFE: NSS auto-reload nsswitch.conf
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 8.1
Hardware: All Linux
medium
medium
Target Milestone: rc
: ---
Assignee: glibc team
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Keywords: FutureFeature, Reopened
: 1065009 1662470 (view as bug list)
Depends On:
Blocks: 1420851 1473733 1477664 1110700
TreeView+ depends on / blocked
 
Reported: 2004-09-15 01:40 UTC by Craig Lawson
Modified: 2019-01-10 17:48 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-28 00:47:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1662470 None CLOSED Resurrection of auto-reloading /etc/nsswitch request 2019-02-22 11:57 UTC

Description Craig Lawson 2004-09-15 01:40:14 UTC
Version: glibc-2.3.2-95.27

When the NSS subsystem parses the contents of /etc/nsswitch.conf, it 
does so only once. While sufficient for short-lived processes, this 
strategy is not appropriate for daemons. If the file has changed, 
each daemon using the file must be either restarted, SIGHUP'ed, or 
who knows what else -- because man pages typically do not document 
how to force nsswitch.conf to reload. Apparently, /etc/nsswitch.conf 
was deemed constant enough that it was not worth mentioning. Yet 
occasionally it does change -- should the user be forced to reboot at 
those times? (PAM faces the same issue, and re-reads its 
configuration file each time.)

RedHat's own authconfig handles this issue by maintaining a built-in 
list of daemons to restart, and when nsswitch.conf is modified, 
restarts them. There is no public interface for additional daemons to 
gain membership to this list, nor for other services which modify 
nsswitch.conf to access the list. The drawback to authconfig's 
approach is that the maintainer must be concerned about proper start-
up dependencies between daemons, new daemons, and the small time 
interval when the daemon is off-line.

The enhancement I propose is that the NSS subsystem reload its 
service_table if the nsswitch.conf has been modified since the last 
time it was read. Optimization: to avoid frequent requests for the 
file's last modification time, which is entirely unnecessary for 
short-lived processes, I suggest omitting file system checks sooner 
than 10 minutes since the last check.

The proposed change simplifies every daemon that uses NSS, makes 
daemon restarts less necessary, simplifies authconfig, and simplifies 
the issues for every sys admin who modifies nsswitch.conf.

Comment 1 Suzanne Hillman 2004-09-15 18:38:55 UTC
Internal RFE bug #132670 entered; will be considered for future releases.

Comment 2 Ulrich Drepper 2004-09-28 00:47:31 UTC
That file will never be automatically reloaded.  The file is not
supposed to be changed after the initial configuration and if it does,
better reboot and restart all relevant programs.  I will not add any
code which penalizes normal operations.

All this can in general be avoided by using nscd.  If nscd is used
only this one program needs to be restarted for the new setting to be
used.  If you need to use change the nsswitch.conf setting for
services other than passwd, group, and hosts then this is something
else.  The solution then might be to add support for these other
services to nscd.

So in summary, us nscd and never let programs directly use NSS services.

Comment 3 Trevor Vaughan 2018-11-28 14:50:27 UTC
Now that we're out of the dark ages of 2004, and inotify is generally everywhere, can we re-open this and set an inotify trigger that re-reads the file if changes.

This doesn't help systems without inotify, but it will at least un-break 90% of the systems out there and make for a better user experience.

Comment 4 Pavel Březina 2019-01-09 12:47:54 UTC
I'm reopening this bug to see if this can be solved for RHEL8.

RHEL8 currently ships authselect, which is a successor of authconfig. Both these tools configures nsswitch.conf per customer requirements. Given the current focus on Ansible and similar automation of system provisioning, it would be very nice to not require system reboot after nsswitch.conf is changed.

In addition, we hit an issue in authselect that requires at least systemd-logind to be restarted to allow authentication of remote users [1]. This is because we made pam_systemd for session phase required [2] instead of optional and of course without fetching changes in nsswitch.conf pam_systemd is not aware of users from newly added passwd modules. This can be worked around in authselect or systemd but it would only solve the issue for this one process. Doing this on glibc level would solve it globally.

Thank you for reconsideration.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1657295
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1643928

Comment 5 Carlos O'Donell 2019-01-09 14:57:59 UTC
We're going to review this during the next development cycle. In general we have been moving certain services to support dynamic reloading via carefully considered semantics. For example we now reload /etc/resolv.conf for dyanmic network changes. In the case of NSS things are a little more complicated, we can't unload any existing services (so RSS goes up if you keep changing services) since they might currently be in use, but we could load new services and transition to using them (may require some slightly different structure for the locking). We will keep this issue updated with any progress, but it might not be until RHEL 9 that we get this fixed. The fix has to get accepted upstream first, and we will want to test it out thoroughly, stablize it, all before we consider inclusion in RHEL.

Comment 7 Carlos O'Donell 2019-01-09 15:59:41 UTC
I want to clarify a few of the expected semantics when it comes to /etc/nsswitch.conf reloading.

There are two aspects to this problem:

(a) Reloading of /etc/nsswitch.conf upon change.

(b) Retrying NSS services which previously failed to load.

Note that (b) is critically important because there is a race where it may not be possible to guarantee that the nsswitch.conf is updated first before the listed module is finished being written to disk. Therefore we must manage both scenarios correctly, and consider their implications on an upstream solution.

Comment 8 Carlos O'Donell 2019-01-09 16:00:44 UTC
*** Bug 1065009 has been marked as a duplicate of this bug. ***

Comment 9 Carlos O'Donell 2019-01-09 16:01:10 UTC
*** Bug 1662470 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.