LEdoian@lanodan I guess that would need to be in userspace, though. IIRC kernel does not have any idea of “appropriate runtime”, nor it wants to enforce particular choices… So maybe keep setuid(2), but allow restricting it to a specific process?
But yeah, having a single reusable implementation for “change the user in a sane way” (possibly in libc) would be so much better, not having to think about all the other nuances like saved UIDs, groups, environment, capabilities, … (This would probably help even setuid (u+s) programs being less bug-prone.)
(btw, the shell in /etc/passwd is IIRC completely unprivileged (tested with an interactive Python as a shell). And even though, some distributions will only allow login if using shell from /etc/shells)
All GNU social JP content and data are available under the