On Mon, Feb 14, 2022 at 09:23:09AM -0600, "Eric W. Biederman" ebiederm@xmission.com wrote:
Pretty much. The function essentially only exists so that we can handle the weirdness of RLIMIT_NPROC. Now that I have discovered the weirdness of RLIMIT_NPROC is old historical sloppiness I expect the proper solution is to rework how RLIMIT_NPROC operates and to remove is_ucounts_overlimit all together.
The fork path could make do with some kind of atomic add+check (similar to inc_ucounts) and overflows would be sanitized by that. (Seems to apply to other former RLIMIT_* per-user counters too.)
The is_ucounts_overlimit() and overflowable increment indeed appears necessary only to satisfy the set*uid+execve pair.
For the sake of bug-fixing, both the patches 5/8 and 6/8 can have Reviewed-by: Michal Koutný mkoutny@suse.com
Michal