Bug 185433 - SELinux denying nscd access to system config files
SELinux denying nscd access to system config files
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2006-03-14 14:50 EST by Josh Kelley
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-14 15:19:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Josh Kelley 2006-03-14 14:50:29 EST
Description of problem:

(This RFE applies to nscd, not glibc as a whole.)  Several times we've had
system config files end up with incorrect SELinux security contexts.  This tends
to cause a number of problems with name resolution if nscd is running, since
SELinux denies nscd permission to access the files.

The system could be made more resilient and could automatically correct these
errors if /etc/init.d/nscd would automatically call restorecon on the
appropriate config files (/etc/resolv.conf, /etc/nsswitch.conf, /etc/ldap.conf,
possibly others) before starting nscd.

Alternatively or additionally, nscd should be noisier about complaining if it
can't read its config files.

Version-Release number of selected component (if applicable):

How reproducible:
always (if files are labelled incorrectly)

Steps to Reproduce:
1. Create /etc/resolv.conf with an incorrect security context.
2. Restart nscd.
Actual results:
"getent hosts" doesn't work.

Expected results:
System recognizes error and either fixes it or complains loudly about it.

Additional info:
Comment 1 Jakub Jelinek 2006-03-14 15:19:11 EST
That's a bad idea.  Running restorecon would only unnecessarily slow
nscd startup down in the 99.99% cases where files are properly labeled.
Audit messages if SELinux denies access to some file are IMHO quite informative.
Comment 2 Josh Kelley 2006-03-14 15:52:24 EST
I thought that restorecon runs quickly enough, and nscd is started rarely
enough, that a small delay would be acceptable in order to prevent certain
classes of errors.

I noticed that Red Hat takes a similar approach for other services now - ldap,
dhcp, and httpd all perform certain checks before starting or restarting in
order to cut down on configuration errors.  Since nscd is a core system
component, I thought it would be worth taking the same approach here.

I don't think that the system is as informative as it should be when trying to
diagnose these kinds of errors - nscd gives no error messages to the console or
syslog, name lookups comes back negative rather than failing with any sort of
error message, name resolution works when nscd isn't running but fails when it
is (I wouldn't expect a cache to alter behavior in this manner).  The audit
messages are informative, but I may not check the syslog immediately in case of
an error, and the audit messages are only logged at boot (which may be due to
some other bug on my system).

I'd like to see RHEL make it easier to diagnose or prevent this condition.  If
calling restorecon in /etc/init.d/nscd isn't the way to do it, then could I log
an RFE for what I perceive as some of the other problems that I listed above
(lack of messages from nscd, name lookups coming back negative instead of
failing, etc.)?

Thank you.

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