Re: Which package is responsible for setting rlimits?
Hi Ansgar,
On Mon, Feb 01, 2021 at 09:50:40PM +0100, Ansgar wrote:
> 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.
I wonder why we must lift them from another process instead of just
providing a hardcoded default, that just sounds hacky. For non-systemd it
still works, so I'm inclined to leave it like that for now as long as we
find a more sensible solution for systemd based setups.
For systemd, resource limits should not be set by pam_limits, because
pam_limits reads /etc/security/limits.conf, while the systemd ecosystem
stores resource limits in the unit files.
> (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).
Teaching pam_limits to interrogate systemd would create a functional
dependency between the PAM and systemd packages where we could only update
them in lock step, so that would be a maintenance nightmare. The systemd
package already provides a PAM module, and this is the perfect place to
apply the configured session limits.
> (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.
It'd probably make sense to ship a non-empty /etc/security/limits.conf, so
we never have to use the fallback.
> 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.
My expectation for a non-systemd system is that I have to explicitly
configure anything but "unlimited", and I will do so if necessary. On most
machines, I won't bother as they aren't exposed to the Internet, there is
only a single user, and if I run "make -j" without specifying a number it's
either intentional or my own fault -- and anything with actual users on it
will likely need application specific limits anyway.
> 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.
In practice, the arbitrary environment is a root shell whose limits have
just been reset by pam_limits, so this is more of an issue for people who
have bad habits like leaving root shells open and not reboot testing their
setups.
Also, I occasionally explicitly restart a service with a different
environment for testing, and being able to do that from a shell by simply
setting a few values with ulimit and calling an init script is immensely
helpful there.
> 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.
Admins shouldn't configure lower limits for root shells, because they share
these limits with a lot of other processes, so a runaway service can easily
lock out the root user by having the shell fail to start.
tl;dr: pam_limits is for non-systemd setups, and only gets in the way of
users configuring limits according to systemd.resource-limits(5). It should
not do anything if pid 1 is systemd so it doesn't interfere, and be split
off into a separate package along with its configuration file to reduce
confusion. The behaviour of copying rlimits from pid 1 in the absence of
explicit configuration is hacky but good enough for the other init systems.
Simon
Reply to: