Re: Fixing multithreaded set*id() AS-safety

[Rich Felker <dalias@libc.org>]

On Sat, Jan 10, 2015 at 05:52:45PM -0500, stephen Turner wrote:
> Does that require any special requirementd in the way of modules or
> settings to use from the kernel? If proc doesnt exist what will happen? A
> kernel panic, absence of threading or will it create the missing folders or
> such?

No. As mentioned (I think) earlier, if /proc is not mounted,
multi-threaded set*id would not be able to work, but would just report
failure. Nothing would blow up. I'm not sure if it's a problem for
multi-threaded set*id not to work without /proc mounted, but in
general:

- Various functions in musl already require /proc to operate correctly
  because the kernel does not provide a way to do the necessary
  operations without /proc. Some of these are less arcane than
  multi-threaded set*id.

- It's rather a bad design to be calling setuid in a multi-threaded
  process to begin with; usually it happens only in Java or other
  "higher level" langs where you're calling out to setuid via some
  native interface and it's hard to prevent multiple threads from
  already existing at that point. These sorts of programs should not
  be running early boot before /proc is mounted.

If failure when /proc is not mounted is really a problem, I'm not sure
how we solve it. But in any case, I think we should start pushing for
the kernel to fix this issue properly: with a syscall that affects all
threads atomically, so that all this mess is used only as a fallback
for old kernels.

Rich