Grzegorz Gutowski (gzegzol) wrote on 2014-04-29: "Without suid it seems that call (with correct username) to getspnam in function get_account_info in file passverify.c in pam/modules/pam_unix returns NULL. I don't understand this behaviour. I wrote a simple c program that calls getspnam and it works as expected when called from unprivileged user."
A call to getspnam(3) as an unprivileged user returns NULL; that's expected. (nss_compat returns errno = EACCESS since we can't read /etc/shadow; nss_ldapd returns errno = ENOENT as a generic "not found" code.)
The unix_chkpwd helper is sgid to shadow so that it can read /etc/shadow, but nss_ldapd still returns ENOENT to shadow queries. If we make unix_chkpwd suid, then nss_ldapd returns real shadow results; but this is only a workaround (and a potentially dangerous one, at that).
What I see happening when I attempt to unlock the screen:
- the auth stack is fine;
- in the account stack, pam_unix returns PAM_AUTHINFO_UNAVAIL (from unix_chkpwd), and it falls into pam_deny after that (since pam_ldap is Additional).
- chmod u+s /sbin/unix_chkpwd (potentially dangerous, not recommended);
- dpkg-reconfigure libnss-ldapd and disable the shadow service (then pam_unix doesn't try consulting it);
- use libnss-ldap instead of libnss-ldapd, since it allows everyone to read shadow entries;
- use libnss-sss instead of libnss-ldapd, since it does not support the shadow service at all (in trusty, at least);
- make libpam-ldapd's account rule Primary instead of Additional (but this was already done and subsequently reverted by its maintainer in 0.8.8-1 and 0.8.8-2).
I'm not sure why some people reported experiencing this bug when using libnss-ldap or libnss-sss. I'd want to review their PAM and NSS setups in that case.
This is all about trusty so far... still have to look at utopic/vivid.
Hi,
Grzegorz Gutowski (gzegzol) wrote on 2014-04-29: "Without suid it seems that call (with correct username) to getspnam in function get_account_info in file passverify.c in pam/modules/ pam_unix returns NULL. I don't understand this behaviour. I wrote a simple c program that calls getspnam and it works as expected when called from unprivileged user."
A call to getspnam(3) as an unprivileged user returns NULL; that's expected. (nss_compat returns errno = EACCESS since we can't read /etc/shadow; nss_ldapd returns errno = ENOENT as a generic "not found" code.)
The unix_chkpwd helper is sgid to shadow so that it can read /etc/shadow, but nss_ldapd still returns ENOENT to shadow queries. If we make unix_chkpwd suid, then nss_ldapd returns real shadow results; but this is only a workaround (and a potentially dangerous one, at that).
What I see happening when I attempt to unlock the screen:
- the auth stack is fine; UNAVAIL (from unix_chkpwd), and it falls into pam_deny after that (since pam_ldap is Additional).
- in the account stack, pam_unix returns PAM_AUTHINFO_
gnome-screensaver works only because it actually ignores the result from the account stack and proceeds anyway: http:// bazaar. launchpad. net/~ubuntu- branches/ ubuntu/ trusty/ gnome-screensav er/trusty/ view/head: /src/gs- auth-pam. c#L519
Some possible workarounds are:
- chmod u+s /sbin/unix_chkpwd (potentially dangerous, not recommended);
- dpkg-reconfigure libnss-ldapd and disable the shadow service (then pam_unix doesn't try consulting it);
- use libnss-ldap instead of libnss-ldapd, since it allows everyone to read shadow entries;
- use libnss-sss instead of libnss-ldapd, since it does not support the shadow service at all (in trusty, at least);
- make libpam-ldapd's account rule Primary instead of Additional (but this was already done and subsequently reverted by its maintainer in 0.8.8-1 and 0.8.8-2).
I'm not sure why some people reported experiencing this bug when using libnss-ldap or libnss-sss. I'd want to review their PAM and NSS setups in that case.
This is all about trusty so far... still have to look at utopic/vivid.