About the Behavior of pam_limits...
IMHO: The purpose of this type of option (applied to a group) is to
*prevent*
a *group* of users overusing a limited machine (i.e: inadvertently from
doing
a DOS :-). Example 1: An educational institution limits 'student' logins,
to
ensure that teachers or administrators can log in.
Example 2: Anonymous FTP is limited to prevent overloading the machine,
but it is desired for 'internal' users to log in anyway.
DoS attacks against this feature imply that the user has already been
authenticated and is a valid user of the system; This can (and IMHO should)
be dealt with either socially or administratively.
** Doug Fajardo
As for membership in multiple groups...
On Thu, 14 Mar 2002, Nalin Dahyabhai wrote:
> > Try this:
> >
> > * hard maxlogins 2
> >
> > and see how many users will be able to login. This is _not_ desired
> > behaviour.
>
> Actually, you're pointing out a bigger problem with pam_limits -- large
> chunks of its behavior are poorly defined, or completely undefined.
>
> For example, look at this configuration line:
> @users hard maxlogins 20
>
> Does the sysadmin want to limit each member of the group to 20 logins
> each (where members bob and joe can log in 20 times each), or limit the
> number of logins by all members of the group at the same time (allowing
> bob to only log in 5 times if joe is already logged in 15 times)?
I think we should check how it behaved till now and just document that.
It's the safest way. And IMO limiting each member of the group make more
sense than entire group. If you apply it for all members it makes a nice
DoS.
> I've stared at pam_limits for lengthy periods of time, and I have no idea
> what the module's supposed to do here. How about this:
>
> @users hard maxlogins 10
> @admins hard maxlogins 20
>
> If you have a user who is in both groups, what's supposed to happen?
