nslcd only allows processes with UID==0 (as determined by credentials
passed over its UNIX domain socket) to query the shadow database.
This check is enforced by lines 449-452 of nslcd/nslcd.c:

    case NSLCD_ACTION_SHADOW_BYNAME:    if (uid==0) (void)nslcd_shadow_byname(fp,session);
                                        else log_log(LOG_DEBUG,"denied shadow request by non-root user"); break;
    case NSLCD_ACTION_SHADOW_ALL:       if (uid==0) (void)nslcd_shadow_all(fp,session);
                                        else log_log(LOG_DEBUG,"denied shadow request by non-root user"); break;

This is a problem because it means non-root processes, in particular
processes with GID shadow, are unable to authenticate against LDAP
via PAM.  Although pam_authenticate() succeeds (since it works by
attempting an LDAP bind with the user's password), pam_acct_mgmt(),
which needs to consult the shadow database for the password expiration
fields, fails.  This breaks a popular paradigm in Debian, which is to use
a setgid-shadow binary to allow non-root services to authenticate with PAM
(since the shadow group has read access to /etc/shadow).  For example, the
pwauth package installs the pwauth binary setgid-shadow, and ejabberd's
README.Debian file advises administrators to use dpkg-statoverride
to make ejabberd's epam binary setgid-shadow.  (Actually, ejabberd's
README.Debian erroneously states that if you're using PAM+LDAP, no
elevation of privileges is needed at all.)

It's understandable why nslcd would want to restrict access to the
shadow database, but in many LDAP environments this is an unnecessary
restriction: if the LDAP server doesn't allow the userPassword attribute
to be read, any user (root or otherwise) who queries the shadow database
would see only '*' for the password hash.

This behavior also makes libnss-ldapd inconsistent with libnss-ldap.
With libnss-ldap, any user is allowed to query the shadow database
(but of course sees only '*' for the password if the LDAP server is
properly configured).

It would therefore be nice if this restriction were configurable, or if
the restriction could be loosened to also permit processes with GID shadow
(making it analogous to the permissions on /etc/shadow).

Note that the versions of nslcd in squeeze and wheezy are also affected
by this.

Control: found -1 nss-ldapd/0.6.1
[...]
getent shadow only returns information for root users (or group shadow
users as it turns out).

The shadow information basically consists of two parts:
- the password hash
- the password and account expiry and related information

The password hash should only be available to privileged users, the
other information is probably less sensitive. However, I can imagine
environments where the other information should also not be public.

Note that, as an extra precaution, by default nslcd maps the
userPassword attribute to "*" so you have to make a conscious decision
to expose password hashes through nslcd.

Determining who can see what information consists of basically two
separate decisions (where those who have access to the hash are a subset
of those who have access to the other information).

(there is actually a third case because nslcd can, under specific
circumstances, expose password hashes as part of the getent passwd
request but that could be analogous to the access to the shadow hash
decision)

Suggestions as to how to specify this in the configuration file are
welcome. I am looking for a proper solution for this.

As a quick fix I could also make a patch that also returns the shadow
information to requests from processes with group shadow. Such a patch
could perhaps be considered for wheezy (if approved by the stable
release team).

Some workarounds that are available as of now:
- make the pwauth binary suid root (obviously not ideal)
- remove ldap from the shadow line in /etc/nsswitch.conf

The second option should result in pam_unix skipping the authorisation
check (when using nslcd 0.8.4 or newer). Since nslcd performs the same
checks (which should still be performed) this should not be a problem.

Thanks for your bug report pointing out the shadow group,

Perhaps a lightweight ACL syntax like:

	allow|deny MAP from user USER|group GROUP|all

For example:

	allow shadow from user root
	allow shadow from group shadow
	deny shadow from all

(Earlier ACLs would take precedence.)

You could have similar syntax for mapping attributes, such as:

	map shadow userPassword userPassword from user root
	map shadow userPassword userPassword from group shadow
	map shadow userPassword "*" from all

(to expose userPassword only to root and shadow)

This is way more flexibility than I (and probably most people) would
need but it seems like the most general solution.

That seems like a nice quick fix.

Thanks for the info about the second workaround.  When we upgrade to
Wheezy that's probably what we'll do.  There shouldn't be any downside
to removing ldap from the shadow line in nsswitch.conf, right? I can't
think of any.

For now I've gone with the first workaround.  It's not ideal but
upstream pwauth actually ships setuid-root so I don't feel *too* bad
about it.

Sure thing.  Thanks for your work on Debian!

[...]

That seems an interesting approach, especially when combined with the
attribute mapping. It will be some work to implement though so don't
hold your breath ;)

Attached is a patch that should work for 0.8.10-4.

Note that getting the client credentials works on most platforms except
GNU Hurd (and Solaris 8).

Thanks,

An alternative solution would be to also return shadow information to
non-root users but leave out the password hashes. This is what pynslcd
in experimental currently does.

I *think* that is reasonable and don't see any security issues from
exposing the other information from the shadow database.

Comments welcome.

The ACLs are a nice idea but I don't see them happening really soon
unless someone steps up for this.

I agree.  The other shadow information is not very sensitive and I
suspect that in many cases it could be accessed by directly querying the
LDAP server anyways.

That's understandable.  I don't think many people need that much
flexibility, so it's probably not a big deal.