Bug 485955 - limits.conf man page doesn't warn that setting "nofile" to "unlimited" or "-1" is a bad idea
Summary: limits.conf man page doesn't warn that setting "nofile" to "unlimited" or "-1...
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
(Show other bugs)
Version: 11
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Documentation
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-17 17:08 UTC by Nils Philippsen
Modified: 2009-07-03 13:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-03 13:48:20 UTC
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 17:08 UTC, Nils Philippsen
no flags Details

Description Nils Philippsen 2009-02-17 17:08:08 UTC
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 14:54:12 UTC
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 11:28:01 UTC
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 13:48:20 UTC
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.