I believe I may be to blame for this. (I'm also willing to take the blame.) Here is the changelog entry: * pam_limits can handle negative priority limits now (which can apply to the superuser too) - based on patch from Nalin. Also cleanup the error handling that was very sloppy before. Also, courtesy of Berend De Schouwe get the math right on login counting (Bug 476990, 476987, 493294 - agmorgan) It was Berend that got me to realize the basic problem: http://sourceforge.net/tracker/index.php?func=detail&aid=493294&group_id=6663&atid=106663 The brief explanation is that some applications make a utmp entry before calling pam and others only after the user session has started. In this case the single definition in the system-wide limits file is ambiguous. The solution I adopted was to change the default to be what I would like to see (no utmp entry before the session has started) and provide a 'utmp_early' module argument to provide with pam_limits.so . Does this help explain the reason for the change? (This is a fail-secure as opposed to a fail-open change.) In the light of this, what do you want to do? (Without looking over the code again, I'm not clear on the priority setting patch. If you believe it is correct, and doesn't interfere with the -ve limits thing then file a bug report and commit the change.) Thanks Andrew Jan Rekorajski wrote: > > Hi, > I want to congratulate the person who b0rken maxlogins > limit in pam_limits (Nalin?). > Try this: > > * hard maxlogins 2 > > and see how many users will be able to login. This is _not_ desired > behaviour. > I know how to fix it, but I want to leave for the person who broke it. > > Jan > -- > Jan Rêkorajski | ALL SUSPECTS ARE GUILTY. PERIOD! > baggins<at>mimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? > BOFH, MANIAC | -- TROOPS by Kevin Rubio
