Simon Richter writes: > On Mon, Feb 01, 2021 at 12:30:30PM -0500, Sam Hartman wrote: > >> It sounded like you were proposing that pam detect if systemd was pid1 >> and if so, then do what it does today otherwise inherit limits by >> default. > > PAM itself doesn't need to detect anything, the individual modules are > responsible for checking whether their requirements are met, and do > something safe if not. > > The way I see it, we want a pam_systemd module that is responsible for > applying *all* settings configured in systemd units, and that is kept in > sync with the unit file parser, and the pam_limits module to handle the > non-systemd setups.
Systemd doesn't manage much of the "process forked from ssh that is the user's process", so there is no place to configure such limit. Also: +--- | To raise the user's limits further, the available configuration | mechanisms differ between operating systems, but typically require | privileges. In most cases it is possible to configure higher per-user | resource limits via PAM or by setting limits on the system service | encapsulating the user's service manager, i.e. the user's instance of | user@.service. +---[ man:systemd.exec(5) ] So changing this limit for user sessions is currently out-of-scope for systemd and handled by pam_limits on Debian (or whatever else). Ansgar
