Hard Limits For Logins And For Services, Which Are Not The Same

resource-limits

Nothing limits an account on a stock EL 10 host. /etc/security/limits.d is empty - the pam package ships the directory and no file in it - and limits.conf has no active line, so what ulimit -u reports is systemd's ceiling of 4194304 rather than a policy. This role sets hard limits on processes, open files and core dumps, and sets them in BOTH places: a login session reads limits.d, and a systemd service never goes through PAM at all.

No download, and no version to pin. pam and systemd are the distribution. What the role owns is one file under /etc/security/limits.d and one under /etc/systemd/system.conf.d, and what it proves is the number the kernel enforces on a real session and on a real service.

A soft limit is advice; a hard limit is the policy. A process may raise its own soft limit as far as the hard one whenever it likes: measured on a host with no policy at all, where an account moved its soft nproc back to the 4194304 ceiling with one ulimit command. Raising the hard limit is refused - with this policy in force the same account's ulimit -Hu answered "Operation not permitted". Both halves are written, and the live test proves the hard one by trying to lift it.

The same file fails closed one way and open the other. A value pam_limits cannot PARSE is logged ("wrong limit value 'notanumber'") and ignored, leaving a policy that reads strict and is not. A value it cannot APPLY refuses the session: root hard nproc unlimited on a host whose ambient ceiling was lower logged "Could not set limit for 'nproc': Operation not permitted" and every su after it answered "cannot open session: Permission denied". That is how a limits file locks every account out of a host, so this role refuses to write unlimited anywhere and checks before it writes anything.

pam_limits does not bind a service. A transient unit running as the same account had nproc 4194304 and an unlimited core size while that account's login session was held to this policy. /etc/systemd/system.conf.d is the other half, and the live test reads both separately - a role that set only the PAM half would pass a test that only looked at a login.

systemctl daemon-reload is enough for system.conf. It runs as a handler, once, when the file changes. Measured: a transient unit's limits were unchanged immediately after the file was written, and correct after a plain daemon-reload. The common advice to use daemon-reexec is not needed here, and re-executing PID 1 is a heavier thing to ask of a running host.

The number in the filename decides who wins, the opposite way round from sshd. pam_limits reads limits.conf and then limits.d/*.conf in name order, and the LAST match wins, so this role's file is numbered 90. sshd takes the FIRST occurrence of a directive, which is why the ssh-hardening role in this catalogue numbers its drop-in 01. Two drop-in systems in one distribution with opposite precedence, and nothing tells you which is which. The live test plants a competing file numbered 10 and requires this policy to win - without it, the claim is untestable on a host where limits.d is empty.

maxlogins is not shipped. pam_limits counts concurrent sessions from utmp; su - writes no utmp record, so the lane cannot produce a second counted session and the control could be written but not demonstrated. It is in resource_limits_extra_lines' documentation rather than in the defaults.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.