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
