On Mon, 01 Feb 2021 at 11:16:48 -0800, Russ Allbery wrote: > pam_limits also does some things that are unrelated to starting services, > such as setting up limits for interactive user sessions, and I think pure > systemd systems still rely on that?
My understanding was that pam_limits is *only* for limits on interactive user sessions. The only overlap with system services is that interactive user sessions are started by system services (system service: gdm, user session: GUI; system service: sshd, user session: my shell; that sort of thing), and because system services on sysvinit can be (re)started from the context of an undefined execution environment, under sysvinit there's an extra incentive for pam_limits to do its best to undo the effects of that undefined execution environment and get back to something well-defined. However, now that I look at https://sources.debian.org/src/pam/1.4.0-2/debian/patches-applied/027_pam_limits_better_init_allow_explicit_root/ more closely, I can see that sysvinit services might not really be the intended motivation here, because the patch description talks about crossing session boundaries (su'ing from one user to another), which is something that *also* happens from an undefined execution environment. Moving from sysvinit to systemd doesn't actually help at all in that case, because the execution environment is equally undefined under systemd (it was *started* in a predictable state, of course, but the user is free to adjust the rlimits for child processes in su's ancestry, and su has to cope with that). Even if the motivation is su'ing from one user to another, I don't see anything in that patch that wouldn't have an equal effect when moving from "the system" into a user session at login entry points (gdm -> a GUI session, sshd -> a shell, etc.), and it's that situation that sets the rlimits that get used in practice for user sessions. smcv