Description of problem:
when logging into a system via ssh, any settings configured via
/pam_limits.so (in /etc/security/limits.conf) are ignored
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.configure ssh or system-auth to use pam_limits.so in a session
2.log in via ssh
3.observe the limits are not changed
ssh + pam_limits is working for me... What specific limits are not
Specifically, nofiles was not working when I tested.
Please also note, that this is with privledge seperation on and
Via another problem report, I just realized the underlying problem
here, and now I'm not quite certain its a bug. As it turns out, this
is another issue involving unintended side effectect of the
UsePrivlidgeSeparation setting in ssh. When enabled the
authentication process in ssh is run as the user id attempting to log
in. This means all the code in the pam libraries is executed as that
user ID. When executing pam_limits.so, this implies that any limits
set which increase soft limits beyond thier hard settings, or increase
hard settings at all will fail (as they can only be modified by uid
0). It seems to me that this is simply a limitation of the
PrivlidgeSeparation feature in ssh, and as such isn't a bug.
Sorry, the more I think about the less I think this is a bug, but
rather a limitation of the UsePrivlidgeSeparation Mode of ssh. This
is really a dup of 115442
*** This bug has been marked as a duplicate of 115442 ***
I think you've got it mixed up. The unprivilged portion of ssh
handles the network traffic, the privilged portion does the
authentication and calls pam. It has to have root access; how else
would it access /etc/shadow for example?
Sorry, it was me mis-speaking. Limits are set during session set up
(a session directive in the pam configuration), which is part of the
user owned process.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.