[PATCH] Error checking for SETXID (bug 13347)
Rich Felker
dalias@aerifal.cx
Mon Mar 24 15:50:00 GMT 2014
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. 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. I'll admit it's
unlikely that this is possible, but you can reduce the chances of
failure by temporaily setting RLIMIT_NPROC to infinity before making
the syscalls.
Rich
More information about the Libc-alpha
mailing list