From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.8-BlackBlueP4-freeswan-1.9 i686) Description of problem: If there is any group which has an entry in /etc/security/limits.conf then its members have some interesting features: when a member of such a group logs in via /bin/login (not ssh or su) then for some reason he/she gets the UID of the user who logged in just before him/her. How reproducible: Always Steps to Reproduce: 1. Create a test group and add an entry for in /etc/security/limits.conf: groupadd testgroup echo '@testgroup - maxlogins 2' >> /etc/security/limits.conf 2. Create a test user with the gid of the group you just created: useradd -g testgroup -G testgroup testuser 3. Login as any user (why not root?!:) ) by any method (console, ssh, telnet, rsh, etc etc). 4. Login as testuser by any method _using /bin/login_ (telnet, console) and enjoy !:) Actual Results: Testuser has a shell with UID=0 instead of his UID... and also GID=0. The additional groups are kept. Expected Results: testuser should have his UID and GID. Additional info: I noticed the bug after upgrading a rh7.1 machine having also older packages... from rh7.0beta. I can see that the tools from rh7.0beta do not have this bug, but there is in 7.0 final release. The bug was tested on two systems, rh7.1 (upgraded from 6.2/6.0 to 7.0beta and so on until 7.1 and current rawhide) havind the following packages version: util-linux-2.10s-12, pam-0.75-7, pwdb-0.61-1.1 util-linux-2.10s-13.7, pam-0.74-22, pwdb-0.61-1.1
I forgot: you have to add the following line in /etc/pam.d/login file: session required /lib/security/pam_limits.so ...in order to make the limitations made in limits.conf to work all the time. For any reason they do not work all the time or as the should do.
This bug does not exist in the pam package shipped by default with redhat 7.0, neither in the updates. I just checked and I also downgraded pam-0.75 and 0.74 to 0.72 from rh7.0 upgrades.
another problem is that limits in limits.conf is taken globally as for ex: * - maxlogins 10 will allow max 10 users on the system instead of max ten logins per user.
I'm requesting that PAM problem treated as a security problem with high priority. It is impossible to manage large systems with 3000 users without limits.
It looks like an additional check (checking if the group in question is the user's primary group) is causing this, and it's a messy problem. I think it'll be fixed in -11, but it needs more testing.
Hello, I would like to confirm this bug, because I have posted to bugtraq test with other results... Anyway: There is a little test: lt:~# cat /etc/security/limits.conf |grep -v "#" @test - maxlogins 2 lt:~# cat /etc/pam.d/login #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so session required /lib/security/pam_limits.so lt:~# id test uid=503(test) gid=509(test) groups=509(test) Only root is login on console tty1 Now, I try login as user test on tty2: login: test Password: Last login: Sun Sep 9 18:29:38 on tty2 lt:~# id uid=0(root) gid=0(root) groups=509(test) Taadam. :-) If I remove line @test - maxlogins 2 from /etc/security/limits.conf or line session required /lib/security/pam_limits.so from /etc/pam.d/login it works correctly, i can login as test on tty2 without root privilege. :-) login: test Password: Last login: Sun Sep 9 18:29:28 on tty1 lt:~$ id uid=503(test) gid=509(test) groups=509(test) lt:~$ bash-2.05$ rpm -q pam pam-0.74-22 bash-2.05$ uname -r 2.4.9
I've been doing some more checking, and it appears that it picks up the first user logged in /var/run/utmp (not the most recently logged in user necessarily). If there are no other users logged in, then the bug does not trigger.
Verified ok with the newer pam (although it can't count user limits right) Closing this bug, opening a new one with the off by one user error in it