Bug 485955 - limits.conf man page doesn't warn that setting "nofile" to "unlimited" or "-1" is a bad idea
limits.conf man page doesn't warn that setting "nofile" to "unlimited" or "-1...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: Documentation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-17 12:08 EST by Nils Philippsen
Modified: 2009-07-03 09:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-03 09:48:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
file setting the login limit of "nofile" to unlimited (95 bytes, text/plain)
2009-02-17 12:08 EST, Nils Philippsen
no flags Details

  None (edit)
Description Nils Philippsen 2009-02-17 12:08:08 EST
Created attachment 332254 [details]
file setting the login limit of "nofile" to unlimited

Description of problem:
Setting the "nofile" limit to "unlimited"/"-1" isn't possible, as can be seen by stracing a shell and running "ulimit -H -n unlimited" in it:

[...]
setrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=RLIM_INFINITY}) = -1 EPERM (Operation not permitted)
[...]

I assume the arrays holding file descriptors/handles are statically allocated when a process is created, so this limitation is sensible from my POV.

It would be good to have this documented in the manpage limits.conf(5) because some admins might use this illegal setting ("more is better") for some or all of their users. This effectively locks affected users out of the system, because setting the relevant limit failes (I assume that happens in pam_limits.so).

Version-Release number of selected component (if applicable):
pam-1.0.2-2.fc10.x86_64

How reproducible:
Reproducible.

Steps to Reproduce:
1. Copy the attached file 90-nofile-bomb.conf to /etc/security/limits.d/ while keeping a root shell open (or set "nofile" to "unlimited" by editing /etc/security/limits.conf)
2. Try to log into your system via ssh
  
Actual results:
[root@gibraltar limits.d]# tail -f /var/log/secure
Feb 17 18:01:46 gibraltar sshd[10002]: Accepted password for nils from 127.0.0.1 port 51477 ssh2
Feb 17 18:01:46 gibraltar sshd[10002]: pam_unix(sshd:session): session opened for user nils by (uid=0)
Feb 17 18:01:46 gibraltar sshd[10002]: error: PAM: pam_open_session(): Permission denied

If you have an open shell, you can fix it easily (if you know what went wrong, the log messages aren't exactly helpful here). If not, it's time for single user mode or the rescue image.

Expected results:
- limits.conf(5) man page and/or comments in /etc/security/limits.conf warn about not setting "nofile" to "unlimited" or "-1" before admins do stupid things.
- more helpful log message?
Comment 1 Nils Philippsen 2009-02-18 09:54:12 EST
Perhaps this could be added in a generic section for "<value>" which seems to be missing from the man page (the "<domain>", "<type>", "<item>" fields are described).
Comment 2 Bug Zapper 2009-06-09 07:28:01 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Tomas Mraz 2009-07-03 09:48:20 EDT
There are zillion ways how ignorant admin can shoot his own foot with PAM and I don't think we will be ever able to document them all. So currently I think we should leave the man page as is.

Basically admin should carefully test every PAM configuration change first.

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