Changing back to per-thread credentials on Linux (fixing native AIO).
jlayton at samba.org
Mon Jul 2 06:13:38 MDT 2012
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, 01 Jul 2012 19:44:25 -0400
simo <idra at samba.org> wrote:
> On Sun, 2012-07-01 at 20:38 +0200, Volker Lendecke wrote:
> > On Sun, Jul 01, 2012 at 12:26:54PM -0700, Jeremy Allison wrote:
> > > On Sun, Jul 01, 2012 at 08:29:39PM +0200, Volker Lendecke wrote:
> > > >
> > > > 1. Just declare the glibc posix aio implementation unusable for
> > > > us. Let's make your aio_pthread module the built-in
> > > > standard. This does not use signals and thus does not have
> > > > the problem. We can provide the native posix aio as a module
> > > > as we are doing it now with aio_pthread.
> > >
> > > That's not a bad idea, but doesn't affect the per-thread
> > > creds code as it is needed for the thread-implementations
> > > of open() and the other calls I'm planning.
> > >
> > > > 2. Let's contact the glibc maintainers for an official
> > > > per-thread credential API.
> > >
> > > The official per-thread creds API *is* the raw
> > > system call API. There's no need to them to add
> > > another API, it's already there.
> > Sorry, I just don't trust the glibc folks on this. They used
> > to have a syscall() function that returned -errno. This
> > would have made syscalls portably useable in an environment
> > using clone() without thread local storage (per-thread
> > errno). They deliberately removed this facility, completely
> > crippling clone(). If they feel like it, they will start
> > intercepting syscall() for the setuid-like values. We would
> > not even notice before it is too late. Before this aspect is
> > not officially blessed by the glibc maintainers, I would
> > rather limit this to a very well-audited set of precise
> > glibc versions.
> > Can you get this official blessing in some way?
> Volker, a couple of years back, at a RH Summit (2010 I think) I spoke
> with Uli (then RH and upstream glibc maintainer) about per thread ids.
> He said that using the syscalls directly would have worked. I do not
> know how official this may have been at the time, and I am not sure how
> official an answer you may get now, but intentionally breaking syscall()
> is something I do not see ever happening, it would be stupid and
It took me a minute to parse what Volker was saying but I think I get
it now. Volker, correct me if I'm wrong...
It used to be that the direct syscall scheme would just return an int
(or whatever you liked). Now, the syscall() wrapper generally returns
'-1' on error and sets errno. Since errno isn't thread-local, multiple
threads could clobber each others' error codes.
In light of that, I'm inclined to believe that Volker is correct here
and you'll be best off with some sort of blessing from the glibc folks
on this. A simple, thread-local syscall() function would probably be
quite handy, but that's a rather long rope for hanging onesself. ;)
Jeff Layton <jlayton at samba.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the samba-technical