When system configured to use LDAP authentication with login limit for users in groupDN, pam_unix allow access to user, which has no record in shadow [broken_shadow IS NOT used] and user must not be allowed to login. I wrote a long letter and I wanted to send it into pam-list mailing list, but my email never appeared in list. See the text in attachment. I'm not sure, if this is a feature or bug, but it doesn't work as I expect. The examples are for Debian distro, but the "bug" is also in Gentoo. If you need more information or want to discuss this, send me an email or we can talk on IRC (send request by email). Reproducible: Always Steps to Reproduce: 1. configure system to use LDAP in nss 2. create posixAccounts TESTER-A and TESTER-B and posixGroup and groupOfUniqueNames sshloginusers, include only TESTER-A (as DN) in uniqueMember 3. configure PAM for SSH to authenticate in LDAP 4. configure PAM LDAP to allow login only users from group cn=sshloginusers 5. try to login user TESTER-A and user TESTER-B. Actual Results: TESTER-A should login - OK TESTER-B get error message "You must be a uniqueMember of LOGIN-ALLOWED-GROUP-DN to login." but login is allowed Expected Results: I expect system disables user TESTER-B to login
Created attachment 112554 [details] Email for pam-list mailing list Describes problem limit user access
Hi, thanks for your report, (In reply to comment #0) > I wrote a long letter and I wanted to send it into pam-list mailing list, but > my email never appeared in list. See the text in attachment. probably you haven't subscribed with the right email address Upstream should fix that weakness so that we and other distros (like debian) will be able to upgrade our packages.
(In reply to comment #2) > (In reply to comment #0) > > I wrote a long letter and I wanted to send it into pam-list mailing list, but > > my email never appeared in list. See the text in attachment. > > probably you haven't subscribed with the right email address *** No, I have subscribed with correct address, I have confirmed my subscription (an email has come for confirmation with URL) and I can login in the pam-list management interface with my email address. Also other emails from mailing list come to my email. > Upstream should fix that weakness so that we and other distros (like debian) > will be able to upgrade our packages. *** does it mean that I should report it to PAM Linux (and maybe to libnss-ldap) or have you already reported?
Created attachment 117209 [details, diff] Debian patch to PAM-Linux for Debian 4.0 etch This is debian patch to PAM-Linux for Debian 4.0 etch, applied to PAM-Linux version 0.79, resulting in debian pam packages version 0.79-4
Created attachment 117211 [details, diff] My patch to resolve pam_unix account bug My patch applied to Debian version of PAM-Linux 0.79-4 to deny access for users without shadow record.
Hi guys, I am not C & PAM profi programmer, but I think I found a two bugs in PAM source code regarding to this functionality bug. Both bugs are in the Linux-PAM/modules/pam_unix/pam_unix_acct.c in the function PAM_EXTERN int pam_sm_acct_mgmt: 1) in the code, there is a condition "if (!strcmp( pwent->pw_passwd, "*NP*" )) { /* NIS+ */" for NIS records. If the system do not use NIS, then next condition "else if (_unix_shadowed (pwent))" check if the pwent has shadow record. If shadow record exists, it reads it "spent = _pammodutil_getspnam (pamh, uname);". But if the shadow record does not exist, it returns success (which is IMHO the bug, because on next lines is the test for option "broken_shadow" to get success even if broken shadow record). Therefore I have disabled the "else return PAM_SUCCESS" code. BUT this leads into the next error, because spent is never initialized (see bug (2)) 2) there is not initialized struct spwd *spent; and if there is condition "not NIS and not _unix_shadowed (pwent)", then spent is never initialized, but later it is tested in "if (!spent)" conditions. I think there is possibility, that the value of spent is sometimes NULL and sometimes anything else and therefore the conditions "if (!spent)" sometimes passed. Could you please check it? Thank you very much. Wolf.
I got answer from Debian bug tracker, from Steve Langasek: ----------------------------- No, this is wrong. If no shadow record exists for the user, there are no authorization tasks for pam_unix to handle, and returning success here is the correct thing to do. If that isn't what you *want* to have happen, then you seem to have misconfigured PAM. ----------------------------- In you agree with Steve, please, close this bug, because it is not really a bug. Thank you.
Falco, INVALID?
It seems to be a misconfiguration of PAM and at worst, a software bug, probably not a security bug. Robert, i'm closing that bug, feel free to reopen if you disagree. Perhaps you may want to reassign it to the LDAP team. Debian bug 416628 is not closed yet.
