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?
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).
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
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.