Patchset to add asynchronous open/close to master

[simo]

On Thu, 2012-06-21 at 14:47 -0700, Jeremy Allison wrote: 
> On Thu, Jun 21, 2012 at 05:38:42PM -0400, simo wrote:
> > > 
> > > 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.
> 
> Unfortunately even if I used setfsuid I'd still need
> to wrap setgroups to ensure the thread has the correct
> suplementary groups list.
> 
> I have a patch I'm working on that wraps the
> setreuid/setregid/setuid/setgid/setgroups calls
> (which are the only ones that we use internally)
> and makes them direct syscalls to avoid the glibc
> per-process manipulations.
> 
> This will put us back to the state we *thought*
> we were running in :-), and re-fix the lost wakeup
> problem with raw glibc aio calls.
> 
> Once that is in the aio create code become much
> simpler, as I can remove all the paranoia around
> race conditions and just ensure I'm running the
> thread as the user that invoked the create call.

Neat,
should we add some abort() calls to check the next time glibc decides to
use SETXID on anything ... who know some smart fella may decide to set
it on getpid() :-P

Simo.

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