[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #15 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Rich Felker from comment #14)
> I've seen real-world applications that were _potentially_ affected. In
> particular, Java applications which call setuid at startup (e.g. after
> binding to a port) have often (possibly inadvertently) created threads
> before doing so. It may be very unlikely for setuid to fail in some of the
> threads at system startup, but if restarting a server that aborted due to
> some sort of resource exhaustion, it might be a lot more likely. I never
> attempted to observe the issue actually happening in such apps, however; I
> just noted that it could.

I looked at the Apache jsvc tool, and it changes credentials before
initializing the JVM.  There's a comment suggesting that this dates back to the
LinuxThreads days.  Considering that they also change capabilities (which are
still per-thread and not process-global), there isn't really a way around that.

The jetty-setuid mechanism doesn't check the result of the setuid call, so it's
not vulnerable to this glibc bug, either (because consistent setuid failure
will not result in an abort and leave the service running with elevated
privileges).

Are there any other Java service loaders that could be affected this way, and
for which source code is generally available?

-- 
You are receiving this mail because:
You are on the CC list for the bug.