From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18561 invoked by alias); 24 Jul 2012 18:35:49 -0000 Received: (qmail 18509 invoked by uid 22791); 24 Jul 2012 18:35:48 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jul 2012 18:35:36 +0000 From: "carlos_odonell at mentor dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges Date: Tue, 24 Jul 2012 18:35:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos_odonell at mentor dot com X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00205.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13347 --- Comment #4 from Carlos O'Donell 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.