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

["carlos_odonell at mentor dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #4 from Carlos O'Donell <carlos_odonell at mentor dot com> 2012-07-24 18:35:22 UTC ---
(In reply to comment #3)
> Before I try, I'd like to know what level of quality we're aiming for. The
> difficulty with this issue is that in the case of failure, the process is in an
> inconsistent state (threads do not all have the same uid anymore) and it's
> impossible to back-out the partial change. On Linux, I believe that once at
> least one thread has successfully changed uid, it's impossible for others to
> fail due to ENOMEM (since the same kernelspace privilege object gets used from
> the cache); the only possible failure is due to malicious security modules or
> RLIMIT_NPROC issues on pre-3.1 kernels.
> 
> In musl, I "solved" the issue fully by assuming the above, and refusing to
> setuid at all if the real uid will be changed and we can't temporarily set the
> rlimit to infinity. There's still code that will return an error if some but
> not all threads change uid, but I believe the failure will only happen in the
> real world on the first thread to attempt the change, if any.
> 
> Without that additional workaround (which may be undesirable to some users..?)
> I'm not clear on what setuid should do when some threads succeed and others
> fail. Returning -1 with errno set might imply to the caller that the uid was
> not changed, and some folks I discussed this with in the security field
> recommended that libc should just abort the program rather than return with an
> inconsistent state (different uid in different threads), but from a robustness
> standpoint this is highly undesirable...
> 
> Once there's some agreement on what the policy should be, I can work on a
> patch. Short of that, a patch to at least make it fail with the process in an
> inconsistent state would be better than the current situation (wrongly
> reporting failure).

Answering this question and getting some consensus is part of crafting the
solution. Start by emailing libc-alpha@sourceware.org to get input.

IMO the guiding principle to date has been that we should report failure to the
user and let the user decide what to do. Failing to report a failure is worst
possible defect.

Does that make sense?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.