[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_limits broken in CVS...

I believe I may be to blame for this. (I'm also willing to take the

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:


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.)



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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []