Bug 177119 - Recent SELinux libraries break nscd
Recent SELinux libraries break nscd
Product: Fedora
Classification: Fedora
Component: libselinux (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2006-01-06 09:52 EST by W. Michael Petullo
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-10 17:11:41 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 W. Michael Petullo 2006-01-06 09:52:26 EST
Description of problem:
I recently upgraded both nscd and my SELinux libraries.  After I upgraded to 
libselinux-1.29.3-2, libsepol-1.11.4-1 and libsetrans-0.1.15-1, nscd stopped 
working.  Nscd once again worked after returning the libraries to previously 
installed versions, so I don't think the bug is due to the new nscd package. 

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

How reproducible:
Every time.

Steps to Reproduce:
1.  Install nscd-2.3.90-26, libselinux-1.29.3-2, libsepol-1.11.4-1 and 

2.  Start nscd: "nscd -d"

3.  Execute "id -ng"
Actual results:
After "id -ng" is executed, nscd says something like:

31166: handle_request: request received (Version = 2) from PID 3904

Note that nscd does not print any details.  By disconnecting from my LDAP 
server, I can confirm that nscd IS NOT providing cached NSS data.

Expected results:
After reverting to older versions of the SELinux libraries, "nscd -d" prints 
the following as a result of "id -ng:"

31166: handle_request: request received (Version = 2) from PID 3904
31166:	GETFDGR
31166: provide access to FD 9, for group

Note that nscd DOES print the details of the request in this case.  By 
disconnecting from my LDAP server, I can confirm that nscd IS providing cached 
NSS data.

Additional info:
I had not updated my Raw Hide system is about one week.  So, I am not sure if 
these SELinux library versions are the first to cause this bug.
Comment 1 Ulrich Drepper 2006-01-07 04:20:24 EST
The fact that there is only one line of output shows that the request was denied
by SELinux.  If it starts working again with the old code this means an
incompatibility in the libselinux code.  I'll reassign to that component.
Comment 2 W. Michael Petullo 2006-01-07 08:44:40 EST
The reason I assigned this bug to nscd and not to an SELinux component is that 
I do NOT have SELinux configured to enforce its policy.
Comment 3 Ulrich Drepper 2006-01-07 12:40:16 EST
The test on whether SELinux is enabled and its rules must be enforced is also
made in libselinux.  Maybe this is already a first clue.  We'll se what Dan has
to say.
Comment 4 Daniel Walsh 2006-01-09 13:40:08 EST
We have tried to reproduce this here, with both the latest rawhide and the
versions you specified, and have not been able to reproduce.   Can you update to
the latest rawhide and see if you still have a problem?

Comment 5 W. Michael Petullo 2006-01-10 17:11:41 EST
Well, with the new SELinux libraries everything is fine.  I went back and tried
to reproduce my problem with the previous SELinux libraries and could not.  I
don't have copies of all of the previous packages, so I don't know what caused this.

When I replaced libselinux.so, libsepol.so, and libsetrans.so with previous
versions the problem went away.  Since then, I have not been able to reproduce this.

The problem is gone now.

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