Description of problem: autofs (automount) may use NIS maps even if nsswitch.conf is configured for files only. If the /etc/nsswitch.conf file is configured for "automount: files", this should preclude NIS maps. However, if the local auto.master references a map that doesn't exist locally, the /etc/init.d/autofs startup script assumes this is an NIS map (see lines 210-232). If an NIS map of that name is available, it uses it regardless of the nsswitch.conf settings. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Edit /etc/nsswitch.conf to "automount: files" 2. Edit /etc/auto.master - add "/x auto_x -ro,intr,nobrowse" 3. Create an auto_x automount map on the NIS server. 4. Restart autofs Actual Results: The /x automount will function using the NIS map available from the NIS server. Expected Results: The /x automount should not function, as the NIS map should be ignored.
This is a known problem. Unfortunately, some users depend on this broken functionality. I will look into adding another flag in /etc/sysconfig/autofs.
> However, if the local auto.master > references a map that doesn't exist locally, the /etc/init.d/autofs > startup script assumes this is an NIS map (see lines 210-232). Sorry, I misread this the first time through. Is this a contrived reproducer or do you actually have instances where you run into this problem? Why would you configure auto.master to look for maps that don't exist?
This particular issue is more likely to be encountered accidentally rather than due to a deliberate configuration. We encountered this problem when I was updating a system to have a local map which overrode the NIS map. I couldn't figure out why the system was still using the NIS map instead of the local map -- even when I removed NIS from the /etc/nsswitch.conf file. Eventually I realized that I'd left out the /etc/ in the auto.master file and that autofs was thus assumed it was an NIS map, even though NIS was not included in /etc/nsswitch.conf.
Re: comment #1 I suspect that some users may be depending on this broken functionality because that's how system-config-authentication sets things up (i.e. it doesn't add "nis" to the automount line in nsswitch.conf). If there was a way to change the setting from system-config-authentication, or a related program, then it wouldn't be as much of an issue. But that's a different bug (and it may have even been filed already by someone else for all I know off the top of my head).
Uh, actually, I may be wrong about comment #4. I could be remembering incorrectly, or it could be a bug that has since been fixed. I'll try to double-check this in the next 2 days or so.
Ok, yeah, comment #4 has nothing to do with reality; I should have double-checked my memory against a real box *before* posting that comment, not after. Sorry about the interruption...
I'm not sure why this is still in NEEDINFO. Chaning it back to assigned. I'll work on fixing this. Thanks.
I've just been playing with U5 beta, and it looks like U5 beta has basically the opposite problem as this (see Bug 156035) -- was that perhaps caused by an attempt to fix this bug?
There have been no efforts as of yet to fix this. However, a change in behaviour can be considered a regression, and should be addressed. Thanks for taking the time to give a detailed report. The init script never properly handled this case. For U5, I will ensure that the behaviour matches that of U4. Post U5, we will work on addressing this issue properly. Thanks.
QE ack.
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 3.8 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 3.8 release.
A fix for this issue has just been committed to the RHEL 3 U8 pool. It will be available in autofs versions 4.1.3-178 and later.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0459.html