Bug 113335 - mlock value in limits.conf has no effect on ulimit -l
mlock value in limits.conf has no effect on ulimit -l
Status: CLOSED DUPLICATE of bug 116133
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pam (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2004-01-12 15:15 EST by Greg Marsden
Modified: 2015-01-07 19:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:00:43 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 Greg Marsden 2004-01-12 15:15:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031120 Firebird/0.7

Description of problem:
Setting memlock value in limits.conf does not affect ulimit -l value

[0] gmarsden@ca-build2:~$ ulimit -l
[0] gmarsden@ca-build2:~$ grep memlock /etc/security/limits.conf
#        - memlock - max locked-in-memory address space (KB)
*       soft    memlock         32768
*       hard    memlock         32768
[0] gmarsden@ca-build2:~$ su
[root@ca-build2 gmarsden]# ulimit -l 32768
[root@ca-build2 gmarsden]# su gmarsden
[0] gmarsden@ca-build2:~$ ulimit -l
[0] gmarsden@ca-build2:~$ ulimit -a
max locked memory     (kbytes, -l) 32768

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.see above

Additional info:

Workaround available (above) but not good
Comment 1 Greg Marsden 2004-01-13 13:33:01 EST
"UsePrivilegeSeparation yes" does solve the problem, and uncovers
why this is happening: because ssh forks of a child process to handle
the authentication, that child process invokes the PAM routines but
doesn't have the permissions to set the proper ulimit values.  Then
when the process returns, ssh assumes that the limits have been set
already, and doesn't invoke the PAM stuff again. In this case,
whatever ulimit values are set when ssh is invoked, these values are
passed along to the new login session (this is not correct).

The "right" way to get around this is to tell sshd "UseLogin yes", as
this will reinvoke the pam limits stuff after the authentication
process returns.  The real right way, though, would be to fix either
pam or ssh to ensure that the right limits are set.
Comment 2 Greg Marsden 2004-01-13 14:13:02 EST
That should read "UsePrivilegeSeparation no" in the first line.
Comment 3 Greg Marsden 2004-04-07 15:14:26 EDT
This is fixed in SSH version 3.8, not sure if it's been packaged for
distribution though.
Comment 4 John Caruso 2004-07-14 21:21:02 EDT
Me too.

This bug can have *very* serious implications for Oracle sites 
running large SGAs; see bug 127897 for details.
Comment 5 Neil Horman 2004-08-26 09:39:14 EDT

*** This bug has been marked as a duplicate of 116133 ***
Comment 6 Red Hat Bugzilla 2006-02-21 14:00:43 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.