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