Bug 173902 - The default /etc/security/limits.conf file should have defaults for all fields to give consistent operation
The default /etc/security/limits.conf file should have defaults for all field...
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Depends On:
  Show dependency treegraph
Reported: 2005-11-22 08:38 EST by Russell Coker
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-17 04:18:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Suggested default values for /etc/security/limits.conf (663 bytes, text/plain)
2005-11-22 08:40 EST, Russell Coker
no flags Details

  None (edit)
Description Russell Coker 2005-11-22 08:38:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.92 (like Gecko)

Description of problem:
Currently the limits.conf file has no active entries, therefore the values 
assigned to processes started from su will be determined by the values from 
the calling process.  This means that daemons started by such mechanisms 
(including the change I suggested for runuser) will behave inconsistently 
depending on whether they are started by system boot scripts or the 
administrator shell. 
To give consistent operation I believe that every value should have a default.  
I will attack a sample file to demonstrate. 
Also the "nice" value does almost exactly the opposite of what you expect 
based on the comments in the limits.conf file and I have been unable to 
determine how to set the limit on pipe size. 

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

How reproducible:

Steps to Reproduce:
Set a low ulimit, run "su - someuser" and observe that the su session inherits 
the limit. 

Additional info:
Comment 1 Russell Coker 2005-11-22 08:40:10 EST
Created attachment 121345 [details]
Suggested default values for /etc/security/limits.conf
Comment 2 Tomas Mraz 2005-11-22 09:36:40 EST
The pipe size is not a real settable rlimit.

As for the:
"Also the "nice" value does almost exactly the opposite of what you expect 
based on the comments in the limits.conf file and I have been unable to 
determine how to set the limit on pipe size."

Do you have any ideas how to improve that comments? I'm afraid it will always be
a little bit confusing.

I'm still not sure setting the default limits is a good idea or not.
It should be discussed with a bigger audience first.
Comment 3 Kenneth Topp 2005-11-24 02:10:15 EST
why shouldn't this be the burden of the system administrator?  How is the limit
being dropped in the first place?  If it's by the user, then they brought the
mess upon themselves, if it was by the SA (in limits.conf presumably) then they
should have set sane wildcard limits if this is what they intended at the same
time of dropping someone else.   The issue seems best served by a nice
description of the issue in a comment section in limits.conf.

From a RHEL perspective, as soon as it's set, it will inevitably be wrong for
most environments and everyone must customize this file so having it set by
redhat just causes more work.

However I don't see any issue explicitely setting things from a fedora user
standpoint except for the far deviations from the kernel defaults for two reasons:

1) bad settings:
As for the proposed  "hard core 0" that seems very wrong and will upset support
groups wanting users to generate cores now and then, and "hard nofile 1024" will
break many azureus downloads.  I'm not sure what value there is to restricting
the hard stack size, but I'm sure 10megs isn't enough for some code out there.

2) ways around it:
Also, there are still ways in a system outside of pam_limits.so (most notably
from my perspective krb5-workstation's rlogind and rshd, although I'd suspect
httpd's suexec as well), are these going to be pamified too?  If not, then users
will still be surprised..
Comment 4 Tomas Mraz 2005-11-24 05:23:26 EST
Well the 1) could be fixed by setting the hard values higher for some limits.

However I agree that the default limits should stay set in the kernel. The 2)
convinces me to not set the defaults in limits.conf.
Comment 5 Russell Coker 2005-11-24 06:58:09 EST
Kenneth, please do some tests! 
You claim that the "hard nofile 1024" limit is wrong, however that is 
precisely what happens at the moment in RHEL4!  If you don't like it then you 
should WANT to do something similar to what I request however with different 
The "hard core 0" is something that can easily be changed, I merely suggested 
some values that have a reasonable correlation to values that are currently 
used.  We can have "hard core unlimited". 
As for issue 2, PAM is the canonical way of managing logins.  In RHEL4 both 
in.rshd and in.rlogind use PAM.  The kerberised login programs work 
differently, I think that this should be regarded as a bug in those programs. 
Comment 6 Steve Grubb 2005-11-24 10:43:41 EST
I think that the problem is being solved the wrong way. The bash shell can set
rlimits. If it is desired to control a daemon's settings, changes need to be
made to the init scripts to set the rlimits in the startup for the daemon. This
way, it doesn't matter what account you use to restart a daemon. Besides, I
think that a shell should have lower limits than a daemon.

I think there is a need for having hooks to set the limits, but pam is the wrong
place for daemon control.
Comment 7 Kenneth Topp 2005-11-26 11:38:07 EST
Some additional thoughts.  I never said RHEL4 is correct :), just that you will
not find wildcard settings that will make everyone happy.  I do think that
putting the burden on all software is also not nice (and also wouldn't work
unless you were running as root since only root could increase hard limits which
maybe necessary), which brings me to my compromise:

put in @daemon entries that match the kernel defaults.  This would reset root
and all other daemons to good values.  Of course those could be superceeded by
other @group entries put after the @daemon entries or specific user entires put
either before or after, but this makes sense at least defensivly if random
people start putting in wildcard entires with lower limits for general usage.

Sorry for flipping on this issue, but I do feel that it's not forced upon you
like a wildcard would be,  since inclusion to the daemon group is optional.  Of
course most daemons aren't in the daemon group, but that shouldn't be too hard
to fix (nor would it be necessary since it's not like there's a su - httpd for
apache startup)
Comment 8 Russell Coker 2005-11-26 16:09:04 EST
In regard to Steve's comment.  Our experience with SE Linux suggests that  
daemons should have lower limits than shells.  Determining that a certain type  
of access is not required is easier for a daemon than for a regular user, so  
we can usefully apply limits on daemons without making the default  
configuration fail to perform as expected for many (if any) users.  
In regard to Kenneth's comment.  None of this applies to processes that aren't  
running as root.  PAM is almost impossible to use by non-root processes and is  
impractical for non-root and AFAIK it is not used by non-root.  The usage of  
PAM is in two categories, SUID root programs such as su and processes started  
as root such as login, sshd, cron and runuser. 
Kenneth's suggestion of applying default limits for the daemon group is a 
viable option if we have every daemon that uses su or runuser to be in the 
daemon group.  NB  Many daemons that run as non-root don't use runuser for 
their startup so will not be affected by this.  
Comment 9 Steve Grubb 2005-11-28 08:07:59 EST
Regarding Russell's comment in #8, I would like to add that those daemon's are
either authenticating and/or starting a user session.

We should not depend on user sessions to set limits for daemons. Daemons need to
set the limits they need themselves or their init scripts need to take variables
used to call ulimit. 

This is just like the fact that environmental variables are inherited by
daemons. Daemons that care sometimes set their locale variables in the init
script or make some effort to clear the ones that affect it.
Comment 10 Tomas Mraz 2006-07-17 04:18:58 EDT
I agree with Steve on this issue. /etc/security/limits.conf should be used for
user settings only.

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