Re: Which package is responsible for setting rlimits?

[Ansgar <ansgar@debian.org>]

Hi Simon,

I think there are three aspects in your mail: the behavior of
pam_limits, defaults for resource limits on legacy init systems and some
discussion of sysvinit scripts that seems unrelated:

1. Resources limits set for a system service (e.g. sshd) might not be
   appropriate for a user session opened by the system service.

   Debian's PAM patch seems to be targeted at dealing with this by
   defaulting to restore the "original" values (taken from a process
   assumed to be unconstrained, here pid 1): sshd might have resource
   limits enforced, but the user session calls PAM which lifts the
   limits by default.

   You argue this might not be a good idea as pid-1's limits are
   somewhat arbitrary (in particular when systemd is pid-1) and it might
   be a good idea to consider using some other default.

   Possibilities seem to include:

   (a) Continue as is.

       The limits applied by pam_limit by default might not be
       reasonable as they are intended for systemd's pid-1, not
       arbitrary other processes.

   (b) Have pam_limit query some other source for default values, for
       example get the DefaultLimit*= values systemd uses by default for
       system services or having pam_limit use some default values
       (i.e., duplicating the logic that sets DefaultLimit*= in
       systemd).

   (c) Have some way to query the kernel's initial resource limits and
       use that as default (but doing so would just imply (2.) below as
       this happens on sysvinit systems as far as I understand).

   (d) Have pam_limit default to just inheriting resource limits, that
       is revert the Debian-specific patch.  If an admin configures
       resource limits for system services that provide login services,
       but are not appropriate for user sessions, then the admin is
       responsible for increasing those by explicitly configuring
       pam_limits to raise them.

       As long as sshd, getty, gdm, ... have no explicit (lower)
       resource limits configured, the inherited limits would be
       reasonable by default.

       If sshd, getty, gdm, ... have similar resource limits on
       non-systemd systems, inheriting limits would also be reasonable
       to do there.

   I think (b) or (d) would be better than (a) which might still be
   better than (c).

2. The defaults for resource limits on non-systemd systems are no longer
   a good default and should be changed.

   This is probably true for both for system services and user
   processes, so somewhat independent from the behavior of pam_limits.

3. Init scripts cannot safely be called in arbitrary environments which
   can have arbitrary resource limits not appropriate for the service.

   To be safe, init scripts would need to explicitly set resource limits
   when invoked.  This is also just another bit of the environment that
   would need to be explicitly sanitized, but usally isn't.

   But this is unrelated to what pam_limits does: even when an admin
   *explicitly* configures lower limits for user session, these limits
   *shouldn't* be applied to system services that just happen to be
   (re)started in a user session.

Ansgar