setuid and setgid take locks on Linux

[DemiMarie]

On Linux, setuid and setgid both take locks, so neither is safe to call in the child after vfork(). Instead, use syscall to issue a raw system call to the kernel.

[snoyberg]

I at least don't have enough context to understand this bug report, can you clarify?

[simonmichael]

I wonder if this is related to the fact that rpmlint warns about missing-call-to-setgroups-before-setuid with some haskell executables, such as hledger-web (https://github.com/simonmichael/hledger/issues/1057) and ghcid (https://bugzilla.redhat.com/show_bug.cgi?id=1639089) ?

[bgamari]

I don't believe this is the same issue that rpmlint is complaining about. That being said, I do believe that the rpmlint warning is a real issue that may even lead to privilege escalation. I've fixed this in #148.

[joeyh]

I came here after watching this excellent talk. https://www.phoronix.com/news/Linux-LPC2022-io_uring_spawn

As I understand it, the problem would be if another thread were doing something that took the same lock when vfork is called. The lock would then remain held by that thread, which would be suspended for the duration of the vfork. So use of setuid/setgid in the vfork code path could end up blocking on that lock.

This is not the only such problem I'm pretty sure. There is a todo in cbits/posix/fork_exec.c about a similar issue:

        // TODO: Strictly speaking malloc is a no-no after fork() since it
        // may try to take a lock
        char *buf = malloc(buf_len);

And based on the above talk, it's unsafe to do practically anything in the vfork code path except for exec and exit, so even calls to close() in the path between vfork and exec may be unsafe as well.