This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 2012-07-24 18:15:24 UTC ---
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).

-- 
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]