Re: [5/8] syscall_cred() a system call that receives alternate CREDs

[Boaz Harrosh <bharrosh@panasas.com>]

On 08/04/13 22:45, Jim Lieb wrote:
> We are setting user, primary group, and alt groups in sequence before we do 
> the actual work (read/write/...).  This is a potential TOCTOU race.  Granted, 
> there is little/no real atomic guarantee but implied in the syscall model is 
> that creds don't change for the duration of a syscall.  We go back to 
> userspace multiple times with creds in intermediate state(s).  Signals can 
> happen anytime but are only checked on the way back out of the syscall or we 
> can hold them off at critical times within a single syscall.  Which syscall is 
> is the one where the signal occurred?  In our case, we minimally use signals 
> (do no i/o etc.) but they are still there.  If it is one syscall, we know.
> 

signals are crap long before our case. I would not really care about signals.
The performance argument is good enough for me.

> We currently have an RFC implementation of a "creds wrapper" but it is still 
> in flux and the codiing of all these calls to "get it right" is ugly.  One 
> call, done right would be much better.
> 
> We also have a problem with the setgroups.  We escape in Linux because the 
> kernel doesn't do it process wide and glibc fakes it.  I don't want to depend 
> on that.  In FreeBSD, we can't do it at all since the creds are shared at the 

Sachin found that FBSD might be exactly the same as Linux here. Please talk to
him to make sure?

> proc level.  Note that I am constrained to think about portability and it's 
> easier to sell a new syscall than to hack fundamental kernel structures which 
> is why the "do to all" bit is in glibc...
> 

But yes a new syscall with new defined semantics is definitely a better way
to go. Just for the sake of thread_setgroups such a call is well worth it.
Completely bypass POSIX and be done with it. So strongly yes here.

Bruce, got the point? Current code with the undocumented thread_setgroups is a
POSIX hack. And will break at any given moment in time. Only a new syscall with
defined semantics will ever be correct.

Thanks
Boaz