[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150111040717.GH4574@brightrain.aerifal.cx>
Date: Sat, 10 Jan 2015 23:07:17 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Fixing multithreaded set*id() AS-safety
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
