Re: [PATCH] Error checking for SETXID (bug 13347)

[Florian Weimer <fweimer at redhat dot com>]

On 03/24/2014 04:49 PM, Rich Felker wrote:
> On Mon, Mar 24, 2014 at 04:44:04PM +0100, Florian Weimer wrote:
> > On 03/24/2014 04:32 PM, Rich Felker wrote:
> > > On Mon, Mar 24, 2014 at 03:19:59PM +0000, Joseph S. Myers wrote:
> > > > On Mon, 24 Mar 2014, Florian Weimer wrote:
> > > >
> > > > > Check for syscall error in the SETXID implementation in NPTL (bug 13347).
> > > > >
> > > > > At this point, we can only abort the process because we have already switched
> > > > > credentials on other threads.  Returning an error would still leave the
> > > > > process in an inconsistent state.
> > > >
> > > > This may be the best possible in the absence of a kernel interface for
> > > > setting ids atomically for the whole process, but such an interface would
> > > > be the desired long-term fix, with aborting from the present code just a
> > > > fallback - is there ongoing work to agree such an interface?
> > >
> > > Are you sure you can't make it so that all setuid calls but the first
> > > can't fail?
> >
> > We already are in this situation if application only ever uses the
> > SETXID wrappers, I think.  That's why the test has to resort to
> > directly invoking the syscall.
>
> I don't understand how your message is an answer to the question you
> quoted.

The negations and quantifiers are confusing, so I wasn't sure what you 
were asking.

> I was asking whether there might be a way to setup the
> conditions prior to making the setuid syscalls such that if the first
> one succeeds, the subsequent ones cannot fail.

Not in general, no, because the kernel implementation calls into the 
Linux Security Module framework, whose modules typically implement 
additional preconditions we cannot check in glibc due to insufficient 
information.

--
Florian Weimer / Red Hat Product Security Team