The wrapper fun!

[Andrew Bartlett]

On Sat, 2013-06-08 at 10:03 +1000, Andrew Bartlett wrote:
> On Fri, 2013-06-07 at 13:37 +0200, Andreas Schneider wrote:
> > On Friday 07 June 2013 21:24:31 Andrew Bartlett wrote:
> > > On Fri, 2013-06-07 at 13:19 +0200, Andreas Schneider wrote:
> > > > On Friday 07 June 2013 11:14:42 Andreas Schneider wrote:
> > > > > Hi list,
> > > > > 
> > > > > just for your interest, I've made all wrappers LD_PRELOADable.
> > > > > 
> > > > > http://git.cryptomilk.org/projects/uid_wrapper.git/
> > > > > http://git.cryptomilk.org/projects/nss_wrapper.git/
> > > > > http://git.cryptomilk.org/projects/socket_wrapper.git/
> > > > > 
> > > > > They all have a testsuite now. There are still features missing
> > > > > (recvmsg()
> > > > > in socket_wrapper e.g.) and the testsuites need to be improved too but
> > > > > it
> > > > > works ...
> > > > > 
> > > > > I've also have a working syscall() wrapper, w00t!
> > > > > 
> > > > > 
> > > > > I've started to change 'make test' to use uid_wrapper but it doesn't
> > > > > really
> > > > > work yet.
> > > > 
> > > > I had a bug in uid_wrapper. It's working!!!!
> > > 
> > > So now we can either run 'make test' with --enable-selftest and without?
> > 
> > Now you can run it with optimized binaries.
> > 
> > > I wouldn't want us to rely on LD_PRELOAD totally (very
> > > platform-dependent), but being able to test the binaries that a
> > > distribution such as debian or Fedora ship, which shouldn't be compiled
> > > with --enable-sefltest is a really big win!
> > 
> > On which platforms, we support with Samba 4.0 on, does LD_PRELOAD not work?
> 
> I don't have a reference, but I always remember being told that was
> great for hacks but to be very careful in relying on it. 
> 
> While uid_wrapper would never be installed like this, my last encounter
> with this being used in 'production' was this:
> http://blog.tridgell.net/?p=141
> 
> > My patch currently removes it from the samba tree and relies on LD_PRELOAD 
> > libraries.
> 
> Does that mean users would have to install uid_wrapper et all onto their
> systems before they can run Samba's make test, rather than it being
> bundled?

To further this point.  We recently decided not to try and spin out
tdb/ldb/talloc etc into distinct projects and git repos, and I would
very much desire that we do not spin these even more internal tools
out.  

A large number of our users building the AD DC do run our 'make test',
even with it's unwieldy size, and our build farm hosts run these test
automatically.  It would be a great win for folks to be able to do that
without recompiling Samba, but it would be a loss for them to have to
obtain the correct version of these, and build them with Cmake to return
to being able to just run 'make test'.  

We only just resolved to use just one build system, and while no build
system is perfect, I would strongly desire that whatever we do here we
keep to one imperfect build system, and not return to having multiple
systems. 

The issues that occur in these wrapper libraries are by their very
nature very, very subtle, and I think it is really important that we
build with the version that is known to work with a given build tree.

I've found a number of issues in our wrapper libraries over the years,
and having to install and update those across our build farm hosts would
be a distinct challenge.  I also really want to avoid spending time
debugging issues that turn out to be because we or a user ended up using
the wrong, earlier version of a library.  (Say one that doesn't wrap a
newly used key function, or has an imperfect emulation that causes
subtle bugs). 

> My personal preference would be to have this able to do both - that we
> LD_PRELOAD if we haven't used the #define based wrappers, ensuring
> therefore that we don't loose comparability with systems that define
> these functions in terms of macros, or where LD_PRELOAD doesn't work.
> 
> (Not that MacOS and Samba get along well these days, but I've always
> noticed that everything seems to gain an extra leading _ on that
> platform, for example). 

I hope this explains my concerns more, and provides a way we can move
forward. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org