setxid should change credentials for all threads

[64]

See e.g https://ewontfix.com/17/.

Should this be done in the sysdep or in the libc?

[ArsenArsen]

sysdeps or kernel, frankly, though we should probably provide some cross-thread communication utilities for this and other cases that need it

[64]

Handling this seems really extremely horrible. I don't think many programs use these functions in multithreaded environments, so maybe we could get away with some assertion that no threads are spawned and wait for a proper kernel fix.

[ArsenArsen]

Handling this seems really extremely horrible. I don't think many programs use these functions in multithreaded environments, so maybe we could get away with some assertion that no threads are spawned and wait for a proper kernel fix.

there most likely won't be a proper kernel fix, afaik

I agree that we should do this in the Linux sysdeps until the necessity of a real fix is observed, and it should likely be:

• a global credentials lock that prevents forking and cloning as well as other setxid ops,
• enumerating threads via /proc/self/tasks or w/e it's called,
• setting some atomic counter to the number of threads found,
• deliver each SIG32 or something,
• wait, with a futex+timeout or something, for all threads to change xid,
• if any didn't (counter != 0), abort, else
• iterate Tcbs to find the xid errnos,
• if any but not all failed or if they failed differently, abort, else return errno
• if none failed, return 0

(edit for elaboration: assert thread count == 0, for the time being, if it becomes necessary, implement the above, or try to bargain with the Linux devs)
it's horrible but it is what it is

[avdgrinten]

It's not necessary (or useful) to iterate over /proc/self/tasks since we can simply keep a global list of threads. But the remainder of the procedure sounds right.

[ArsenArsen]

It's not necessary (or useful) to iterate over /proc/self/tasks since we can simply keep a global list of threads. But the remainder of the procedure sounds right.

the usefulness is that it covers the edge case of the program itself cloning without using pthread_create (I think the signal handler should be inherited well enough for this)

[avdgrinten]

If a program does syscall(SYS_CLONE), all hope to implement anything thread-related in a sane way is lost anyway. For example, such threads won't have a working TLS.