Changing back to per-thread credentials on Linux (fixing native AIO).

Volker Lendecke Volker.Lendecke at SerNet.DE
Sun Jul 1 12:29:39 MDT 2012


On Sun, Jul 01, 2012 at 06:57:45AM -0700, Jeremy Allison wrote:
> On Sun, Jul 01, 2012 at 10:42:09AM +0200, Volker Lendecke wrote:
> > Hi, Jeremy!
> > 
> > On Wed, Jun 27, 2012 at 09:51:12AM -0700, Jeremy Allison wrote:
> > > Comments please !
> > 
> > IMHO we need to block or redirect all use of the glibc
> > setX[ug]id calls with LD_PRELOAD or an equivalent mechanism.
> > There might be external libraries subverting our security
> > model by calling them.
> 
> That would be a library that had completely different
> security behavior depending on whether the caller was
> running as root or not, as these functions only work
> as root.
> 
> That would be a security nightmare and I can't think
> of any such library, and as Simo points out would also
> not be thread-safe.
> 
> Remember the userspace NFS server ganesha also depends
> on making these syscalls directly, so they would also
> have the same problems.

Next try, alternative approach in here :-)

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.

2. Let's contact the glibc maintainers for an official
   per-thread credential API.

3. Until we have that, for the open() that you are working
   on lets use a fork-based module, much like aio_fork.

4. When 2. is done, lets remove the fork approach.

I would like to organize a confcall together with the OEM
we're doing all this for to present our ideas and have an
independent arbitrator. When would be a good time for you?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de


More information about the samba-technical mailing list