On 03/06/2025 06:05, Solar Designer wrote: With the PID range reduced from the default of 4M down to 2K, PID reuse is quick even with simple fork(). I am getting frequent unixchkpwd coredumps (without password hashes in them, which is as expected without inotify), but none of them are getting ACLs set for read by the user (unexpected - I thought I'd win this easier race once in a while), e.g.: I admit I didn't look very closely at the specifics of this bug but maybe you could use a setpid() technique like this one?

""" newgrp: fix potential string injection

Since newgrp is setuid-root, any write() system calls it does in order to print error messages will be done as the root user.

Unprivileged users can get newgrp to print essentially arbitrary strings to any open file in this way by passing those strings as argv[0] when calling execve(). For example: $ setpid 31000 $ readlink /proc/self 31001

This is not a vulnerability in newgrp; it is a bug in the Linux kernel.

However, this type of bug is not new [1] and it makes sense to try to mitigate these types of bugs in userspace where possible.

[1]: https://lwn.net/Articles/476947/ """

https://github.com/shadow-maint/shadow/commit/9df4801e0b65073cc8a9031b22a73532ef7fdc2c

Vegard

shadow-utils (aka shadow) 4.4 through 4.17.0 establishes a default /etc/subuid behavior (e.g., uid 100000 through 165535 for the first user account) that can realistically conflict with the uids of users defined on locally administered networks, potentially leading to account takeover, e.g., by leveraging newuidmap for access to an NFS home directory (or same-host resources in the case of remote logins by these local network users). NOTE: it may also be argued that system administrators should not have assigned uids, within local networks, that are within the range that can occur in /etc/subuid.