[Bug 897940] Re: pam_limits not working with pam_groups

[Steve Langasek]

As far as I can see, pam_limits and pam_groups both work as designed.
pam_limits allows you to change the limits for a user based on their
*group membership*.  pam_groups does *not* change the group membership
of a user, it only temporarily grants additional group privileges to the
running process.  pam_limits will always check the system group
information, which is actually what it should do.

So ultimately, what you're asking for here is not supported and that's
not going to change.  However, there are some things you mention here in
your report which don't make sense to me.  These could point to bugs in
packages, but probably just indicate bugs in your setup.

> I also strace'd the login process to see when things are being loaded. pam looks
> at limits.conf at around line 300, while it looks at group.conf at around 7000.
> This is consistent with the problem, but brings us no closer to finding a
> solution.

This probably only indicates when the files are parsed, not when they're
applied.  The pam_groups rules are applied in the auth stack, which
*must* be done before applying the rules for the session stack (which is
when pam_limits runs).  The relevant syscalls would actually be
setrlimit() vs. setgroups().

> In addition, adding an LDAP user to /etc/security/limits.conf
> directly does not work either.

There is no reason this should be the case on a correctly configured
system.  You may want to double-check this for sanity's sake  (though I
understand you're not likely to want to add the users individually to
limits.conf).

> A workaround would be to have a script that will just add all ldap users
> to local groups (once a day, perhaps?). This is not a good option, but
> it may be our only option.

The other conceivable workaround would be to have the group membership
information included as part of the LDAP data and propagated to your
system via nss_ldap; this would prevent the need for any per-user
configuration in either group.conf or /etc/group.  This of course
assumes a degree of control over the LDAP data which may not apply here.

** Changed in: pam (Ubuntu)
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/897940

Title:
  pam_limits not working with pam_groups

Status in “pam” package in Ubuntu:
  Won't Fix

Bug description:
  I have a group of workstations which are used for working with USRPs
  via gnuradio and matlab. gnuradio requires permissions to increase the
  thread priority (granted via pam_limits). Every user who uses these
  machines does so via LDAP accounts (which are also used on other
  workstations). LDAP users are added to the usrp group via pam_groups.
  The limit works fine for local users and for LDAP users manually added
  to local usrp group (entered in /etc/group), but does not work for
  LDAP users who are added to the group via pam_groups. In addition,
  adding an LDAP user to /etc/security/limits.conf directly does not
  work either. Another issue that is possibly related is that calling
  'id' or 'groups' from an LDAP account returns all the local groups
  added via pam_groups, while calling 'id $USER' or 'groups $USER' only
  returns the LDAP groups that the user is a member of. This makes
  sense, because, with no arguments, id and groups return the groups of
  the calling process, while with the username as an argument, it
  queries the user database directly.

  /etc/pam.d/login includes /etc/pam.d/common-auth, so the groups line should run before the groups line.
  I also strace'd the login process to see when things are being loaded. pam looks at limits.conf at around line 300, while it looks at group.conf at around 7000. This is consistent with the problem, but brings us no closer to finding a solution.

  A workaround would be to have a script that will just add all ldap
  users to local groups (once a day, perhaps?). This is not a good
  option, but it may be our only option.

  I posted this to the PAM mailing list (https://www.redhat.com/archives
  /pam-list/2011-October/msg00020.html), but but received no response.

  Is pam_limits and pam_groups not interacting with each other a bug or
  is that design intentional? If it is intentional, are there any good
  workarounds for this situation?

  
  Relevant files and command outputs:

  Ubuntu 11.04
  uname -a: 
  Linux ice04 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

  dpkg -l | grep libpam-:
  ii  libpam-ck-connector                   0.4.4-1                                    ConsoleKit PAM module
  ii  libpam-gnome-keyring                  2.92.92.is.2.32.1-0ubuntu2.1               PAM module to unlock the GNOME keyring upon login
  ii  libpam-ldapd                          0.7.13                                     PAM module for using LDAP as an authentication service
  ii  libpam-modules                        1.1.2-2ubuntu8.3                           Pluggable Authentication Modules for PAM
  ii  libpam-modules-bin                    1.1.2-2ubuntu8.3                           Pluggable Authentication Modules for PAM - helper binaries
  ii  libpam-runtime                        1.1.2-2ubuntu8.3                           Runtime support for the PAM library

  /etc/security/limits.conf:
  @usrp  - rtprio 50

  /etc/security/group.conf:
  *;*;*;Al0000-2400;floppy,video,audio,cdrom,plugdev,users,usrp,wireshark,vboxusers,fuse,dialout

  output of 'ulimit -l -r' on LDAP user not added to usrp via pam_groups:
  max locked memory       (kbytes, -l) 64
  real-time priority              (-r) 0

  output of 'ulimit -l -r' on local user or LDAP user added to usrp via pam_groups:
  max locked memory       (kbytes, -l) 64
  real-time priority              (-r) 50

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/897940/+subscriptions