Bug 173902

Created attachment 121345 [details]
Suggested default values for /etc/security/limits.conf

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.

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

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.

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 
values. 
 
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. 

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.

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)

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.  

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.

I agree with Steve on this issue. /etc/security/limits.conf should be used for
user settings only.