Bug 113335
| Summary: | mlock value in limits.conf has no effect on ulimit -l | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Greg Marsden <greg.marsden> |
| Component: | pam | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED DUPLICATE | QA Contact: | Jay Turner <jturner> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | guru.anbalagane, jcaruso, srevivo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-21 19:00:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
"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. That should read "UsePrivilegeSeparation no" in the first line. This is fixed in SSH version 3.8, not sure if it's been packaged for distribution though. Me too. This bug can have *very* serious implications for Oracle sites running large SGAs; see bug 127897 for details. *** This bug has been marked as a duplicate of 116133 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |
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 4 [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 32768 [0] gmarsden@ca-build2:~$ ulimit -a max locked memory (kbytes, -l) 32768 Version-Release number of selected component (if applicable): pam-0.75-51 How reproducible: Always Steps to Reproduce: 1.see above 2. 3. Additional info: Workaround available (above) but not good