Bug#995236: libpam-modules: pam_limits.so always overwrites rlimits, contrary to man page and upstream behaviour

[Sam Hartman]

>>>>> "Simon" == Simon McVittie <smcv at debian.org> writes:

    Simon> On Thu, 16 Jan 2025 at 15:12:01 -0700, Sam Hartman wrote:
    >> I do think it would be good if su and other privilege gates would
    >> consider using set_all.

    Simon> If so, that's surely a decision for those privilege gates'
    Simon> PAM stacks, not PAM in general.

Absolutely.
I think pam could make recommendations, but my plan was to open wishlist
bugs asking maintainers to consider switching to set_all.


    >> I think it wouldbe be desirable to see if there's some other pid
    >> besides pid 1 we could use for looking at default limits.  At
    >> least on systemd systems, pid 1 is a singularly bad choice for
    >> looking at limits. I wonder if looking at pid 2 if it exists
    >> might be a better choice.

    Simon> In principle there is absolutely nothing special about pid
    Simon> 2. It *might* be a service that happens to have been started
    Simon> during early boot and retained default limits, but equally it
    Simon> might be a service that has set its limits to non-default
    Simon> values, or even an unprivileged process belonging to an
    Simon> attacker.

for a long time on systems I've run, pid 2 on the real system is some
kernel thread; on my current laptop it's kthreadd.
I suspect that in containers you are correct that pid 2 reuse is
possible.
I'm not convinced it's very common for bare metal.
In particular, I wonder whether looking at /proc/2/limits when
/proc/2/exe is an unreadable symlink would be safe.

--Sam