Re: Which package is responsible for setting rlimits?
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
Reply to: