Bug 110944 - ssh ignores values in limits.conf
ssh ignores values in limits.conf
Status: CLOSED DUPLICATE of bug 115442
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openssh (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 2003-11-25 14:25 EST by Neil Horman
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:00:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Neil Horman 2003-11-25 14:25:30 EST
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):

How reproducible:

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
Actual results:

Expected results:

Additional info:
Comment 1 Mark Leary 2003-12-05 00:15:33 EST
ssh + pam_limits is working for me...  What specific limits are not 
Comment 2 Jp Robinson 2004-01-09 09:47:41 EST
Specifically, nofiles was not working when I tested. 
Comment 3 Jp Robinson 2004-01-09 10:06:32 EST
Please also note, that this is with privledge seperation on and
uselogin no
Comment 4 Neil Horman 2004-02-17 08:37:08 EST
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.
Comment 5 Neil Horman 2004-02-20 08:18:18 EST
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 ***
Comment 6 Daniel Stutzbach 2004-08-21 13:49:17 EDT
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?
Comment 7 Neil Horman 2004-08-21 17:01:05 EDT
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.
Comment 8 Red Hat Bugzilla 2006-02-21 14:00:11 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.