I've noticed some very odd behavior of nscd which started happeneing recently: kscd -K run as root won't shut down the running nscd; the following is logged: audit(1118686058.107:0): avc: denied { connectto } for pid=25133 exe=/usr/sbin/nscd path=/var/run/nscd/socket scontext=root:system_r:nscd_t tcontext=user_u:system_r:nscd_t tclass=unix_stream_socket The same goes for nscd -i and -g; they can't access the control socket. The context seems correct: srw-rw-rw- root root user_u:object_r:nscd_var_run_t socket More damaging, though: nscd can't see anything in an ldap directory because it can't read /usr/share/ssl/cacert.pem: audit(1118685536.864:0): avc: denied { read } for pid=6903 exe=/usr/sbin/nscd name=cacert.pem dev=dm-3 ino=278529 scontext=user_u:system_r:nscd_t tcontext=user_u:object_r:usr_t tclass=file This, of course, breaks absolutely everything because all of our users have ceased to exist. Stopping nscd works, but since "service nscd stop" breaks due to "nscd -K" not working, you have to kill it. nscd will still serve information from its cache. Note that there doesn't seem to be an nscd Bugzilla component.
FYI, I rolled back to selinux-policy-targeted-1.17.30-2.96 and while there were errors about unknown booleans things seem to work much better now.
I had problem with Subversion too. (The httpd user cannot write to the Subversion database files.)
nscd is part of the glibc group of packages. But this bug is a duplicate of bug 160038 .
Indeed it is a duplicate. I did a search for "selinux nscd" earlier but got zarro boogs; perhaps I made a typo. nscd used to have its own component, and indeed it shows up in the full list. But it is not shown as a component under FC3. In any case, resolving as a duplicate. *** This bug has been marked as a duplicate of 160038 ***