[Bug 491767] Review Request: nss-ldapd - An nsswitch module which uses directory servers

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=491767





--- Comment #21 from Nalin Dahyabhai <nalin at redhat.com>  2009-04-21 14:20:18 EDT ---
(In reply to comment #19)
> I'm running whatever's in rawhide currently:
>   selinux-policy-3.6.12-4.fc11.noarch
>   selinux-policy-targeted-3.6.12-4.fc11.noarch
> 
> Well, at least I've found that the caching works across reboots.  After logging
> in with setenforce 0, I can reboot the machine (which resets selinux to
> enforcing) and still log in.  But I can't resolve any other users.

Yeah, we're going to have to get that sorted before it gets into any
repositories.

> And indeed, stopping nscd does get things working, but of course nscd caches
> more than uid/gid lookups.

> BTW, do you know if this will cache autofs lookups as well?

It does not; autofs doesn't use libc's nsswitch subsystem to look up automount
information (there's no interface for one, and for such an interface to be
useful right away you'd have to add frontend the functions to libc, and then a
backend for it to the various nsswitch modules, and by doing so duplicate a lot
of code that you need to keep in the automounter until the older versions of
libc that don't provide it go away, so in the end you haven't gained much).

> Finally, to packaging issues: You fixed the minor issues I had; personally I
> don't care one way or the other about the /lib64/security/pam_ldap.so
> dependency.  However, one issue concerns me:
>   /lib64/libnss_ldap.so.2
>   /usr/lib64/libnss_ldap-264.so
>   /usr/lib64/libnss_ldap.so
>   /usr/lib64/libnss_ldap.so.2
> This brings up a couple of issues:
> 
> Does the library really need to live in the root directory?  Generally we try
> not to install things there unless they're absolutely required that early in
> the boot process (or for recovery).  I know it conveniently avoids a conflict
> in this case, but I'm wondering if it's just done that way because of the
> conflict or if there's another reason.  

It doesn't need to live in /%{_lib}, but by convention nsswitch modules,
following largely from what glibc does with its own modules, have been put
there anyway.  In practice, any location in the shared library path will do. 
The main reason to move one elsewhere is admitting that it has dependencies
that will never be satisfiable without a working /usr.

In this case, though, it avoids having to deal with file conflicts or working
something out with alternatives (which I actually tried doing, but trying to
select the "right" one without requiring manual intervention didn't lend itself
to any elegant solutions).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.