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

[Jim Lieb <jlieb@panasas.com>]

On Tuesday, April 09, 2013 00:33:32 Boaz Harrosh wrote:
> 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.

In our case, true.  But this is a syscall and we will be stuck with it 
forever.  The reason for this syscall request, along with the locking request 
it that they were too narrow in scope.  This is, or can be, and issue for non-
threaded apps that do use pollling, signaling, and all the rest.

> 
> > 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?

I checked with Herb et al and they have a hack for CIFS (which scares me a 
bit...) but they confirmed that stock FreeBSD has the creds as a property of 
the proc, not a thread.  Their structure sounds similar to Mach, aka OSF/1, 
aka Digital UNIX which had thread structs only contain the thread specific 
state and left things like creds and open fds in the proc struct.  To handle 
their CIFS need, they added a creds_like (emphasis on the "like") struct that 
gets allocated on a CIFS related event (not sure on details) but this is 
specific to their kernel.  Stock FreeBSD doesn't have it and it doesn't sound 
like we can use it.

> 
> > 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.

And my comments about selinux are to explore/define/get_alarmed about that 
dimension as well given that selinux and friends are another layer/alternate 
universe of access control.  Hmm.  Might need a flags arg in the api...

> 
> Thanks
> Boaz
-- 
Jim Lieb
Linux Systems Engineer
Panasas Inc.