Hi Sam, 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. These two modules should never be active at the same time, but since it is possible for local configuration to load both, this should be detected and fixed up. To my knowledge, pam_systemd already does nothing if the init system isn't systemd, so all we'd need is for pam_limits to do nothing if the init system *is* systemd -- and the same essentially for all the other PAM services that have been subsumed in systemd. Anything else would just create strong coupling between modules in two separate packages, which would require either lots of compatibility code if an API changes, or versioned dependencies in the package system, both telltale signs of a monolith. The PAM maintainers might decide to split off the PAM modules that do nothing in systemd setups, so we can shrink the default installation, but probably after bullseye. Simon
