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

[Rich Felker <dalias at aerifal dot cx>]

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? There are basically only 2 reasons it might fail: ulimit
on old kernels (this was fixed in early 3.x series), and failure to
allocate the kernel data structure to represent the new permissions
(they're refcounted/shared, so this failure can only happen on the
first one under normal circumstances, but might be possible still if
setfsuid, etc. are in use).

I'm very much in favor of pressing the kernel folks for a syscall that
makes the change atomically for all threads, but this is vastly
complicated by the fact that they're storing permissions which should
be thread-local (fsuid) in the same object as ones which should be
process-global. So implementing this correctly at the kernel level
might require radical changes to how they represent permissions... :(

Rich