setuid() syscall on Linux only sets uid of current thread

[shawnl]

we have to set up a signal handler in the other threads to call setuid() and setgid(), and then send the other threads a signal, like glibc does.

[andrewrk]

Thanks for bringing this up. We definitely need to address it. Here's the relevant section from the man page:

C library/kernel differences At the kernel level, user IDs and group IDs are a per-thread attribute. However, POSIX requires that all threads in a process share the same credentials. The NPTL threading implementation handles the POSIX requirements by providing wrapper functions for the various system calls that change process UIDs and GIDs. These wrapper functions (including the one for setuid()) employ a signal- based technique to ensure that when one thread changes credentials, all of the other threads in the process also change their credentials. For details, see nptl(7).

std.os.linux is intended to map to raw Linux syscalls. So std.os.linux.setuid will continue to directly call setuid in the kernel.

However, std.os.posix should be changed to be posix compliant. Right now std.os.posix is assigned directly to either std.os.darwin or std.os.linux, however it will be changed to manually re-export the declarations that are posix compliant from each system, and in some cases, such as setuid, contain a wrapper function to perform this POSIX compliance workaround.

In some cases zig std lib may choose to not implement a posix function, if it is deemed to be too buggy or problematic. This may be the case for setuid. I'll decide when I see the implementation, but "signals" is always a red flag.

[shawnl]

alternatively we could write a patch to Linux, and introduce a new syscall, perhaps setuid_allthreads() and setgid_allthreads().

We need setuid if we wan't to listen to privileged ports and then drop privileges, although this could be worked around by dropping privileges before spawning threads. (go can't do this)

An alternate fix would be to make posix.setuid() fail if there is more than one thread.

[andrewrk]

Related: #2380