Patchset to add asynchronous open/close to master

[simo]

On Thu, 2012-06-21 at 09:33 -0700, Jeremy Allison wrote: 
> On Thu, Jun 21, 2012 at 09:31:47AM -0700, Jeremy Allison wrote:
> > On Thu, Jun 21, 2012 at 08:24:28AM +0200, Volker Lendecke wrote:
> > > On Thu, Jun 21, 2012 at 08:18:33AM +0200, Stefan (metze) Metzmacher wrote:
> > > > > I'll prepare a patch for master/3.6.x
> > > > > to fix this issue.
> > > > 
> > > > I think you need to test with the full unix token,
> > > > not only uid and gid.
> > > 
> > > There's also the per-thread setfsuid and setfsgid
> > > linux-specific calls. But there's no setfsgroups call.
> > 
> > Yes you're right. Looking in the glibc sources
> > setfsuid aren't caught by the SETXID wrappers,
> > so they'll be thread specific on Linux.
> > 
> > What I'm thinking of is adding checks for
> > 
> > syscall(SYS_setreuid,...)
> > syscall(SYS_setregid,...)
> > syscall(SYS_setgroups,...)
> > 
> > and use them by preference inside smbd to
> > restore the semantics we were depending on,
> > (they'll fit inside source3/lib/util_sec.c)
> > and also use them inside worker functions
> > called from a threadpool to set the credentials
> > correctly for the IO operation.
> 
> One more point - the reason for using the
> syscall(XXX, ...) instead of the setfsuid()
> calls is because glibc could change
> in the future to catch the setfsuid() calls
> to do the SETXID uid signalling and we
> wouldn't know. The syscall() interface
> is guarenteed to stay the same on the
> Linux kernel without any glibc interference.

As far as I know setfsuid is meant to escape the posix madness, so that
should not happen as there is software relying on setfsuid exactly to
avoid having the fsuid changed arbitrarily by glibc.
However any seteuid will reset also the fsuid in the kernel, so you
cannot mix seteuid calls with setfsuid ones.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>