Re: pam_limits broken in CVS...

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

 



On Thu, 14 Mar 2002, Nalin Dahyabhai wrote:

> On Thu, Mar 14, 2002 at 08:44:04PM +0100, Jan Rekorajski wrote:
> > 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.
> 
> 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?

Hmm, pam_limits parses entire config file and as far as I remember
always the last match was the right one. Let's leave it like that.
So in this example user that is in both groups is limited as @admins.

> If a patch I submitted to the SourceForge tree or added to Red Hat's
> package changed it to work in a way you don't like, then I'm sorry for
> the inconvenience it's caused you, but I'm glad you found it before it
> went out in an official release.

That inconvenience was students whining they can't log in ;)
IMO the fix (go back to previous behaviour) is as simple as:

Index: pam_limits.c
===================================================================
RCS file: /cvsroot/pam/Linux-PAM/modules/pam_limits/pam_limits.c,v
retrieving revision 1.11
diff -u -r1.11 pam_limits.c
--- pam_limits.c	19 Jan 2002 07:10:46 -0000	1.11
+++ pam_limits.c	15 Mar 2002 13:59:38 -0000
@@ -243,7 +243,8 @@
             continue;
 	}
         if (!pl->flag_numsyslogins) {
-	    if ((pl->login_limit_def == LIMITS_DEF_USER)
+	    if (((pl->login_limit_def == LIMITS_DEF_USER)
+	         (pl->login_limit_def == LIMITS_DEF_DEFAULT))
 		&& strncmp(name, ut->UT_USER, sizeof(ut->UT_USER)) != 0) {
                 continue;
 	    }

And BTW, somewhere along the way you lost the priority setting,
everything is in place but the limit value ;)

Index: pam_limits.c
===================================================================
RCS file: /cvsroot/pam/Linux-PAM/modules/pam_limits/pam_limits.c,v
retrieving revision 1.11
diff -u -r1.11 pam_limits.c
--- pam_limits.c	19 Jan 2002 07:10:46 -0000	1.11
+++ pam_limits.c	15 Mar 2002 14:05:03 -0000
@@ -419,7 +420,9 @@
     } else {
 	/* recent kernels support negative priority limits (=raise priority) */
 
-	if (limit_item != LIMIT_PRI) {
+	if (limit_item == LIMIT_PRI) {
+		pl->priority = limit_value;
+	} else {
 	        if (pl->login_limit_def < source) {
 	            return;
 	        } else {

Andrew, if those one-liners are ok with you I can commit them to CVS.

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





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux