handling nss_winbind during upgrades (was: Re: Debian bug #833287, ubuntu #1584485: feedback request about patch)

[Andrew Bartlett]

On Fri, 2017-06-16 at 11:39 -0300, Andreas Hasenack via samba-technical 
wrote:
> Hi,
> 
> A user filed this samba bug against ubuntu:
> https://bugs.launchpad.net/bugs/1584485
> 
> TL;DR the problem happened during a particular upgrade:
> > Unpacking libnss-winbind:amd64 (2:4.3.11+dfsg-0ubuntu0.14.04.1) over
> 
> (2:4.1.6+dfsg-1ubuntu2) ...
> > dpkg-deb: error: subprocess tar was killed by signal (Segmentation
> 
> fault), core dumped
> 
> That user had winbind in /etc/nsswitch.conf (but strangely, before
> files/compat, not after, not sure why).
> 
> An IRC discussion started, documented in
> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/comments/12
> and later, and making a static build with certain libraries seemed the best
> option. A patch for that was proposed in
> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/comments/17 and
> accepted.
> 
> That introduced a regression (https://bugs.launchpad.net/bugs/1677329),
> however: pam_winbind had unresolved symbols at runtime and couldn't be
> loaded. The patch was reverted, but by mistake added back again at some
> later point (!).
> 
> I'm attaching a new version of that patch that fixes the missing symbols
> problem (bug #1677329), but I'm not familiar with the samba4 buildsystem
> and would like some feedback. I'm still working on the DEP3 header, the
> history of this one is a bit complicated. I uploaded test packages with
> this patch into
> https://launchpad.net/~ahasenack/+archive/ubuntu/samba-1677329/+packages
> and a couple of users confirmed it fixed the missing symbols problem for
> them.

This is a very interesting and challenging set of issues. 

The samba-libs package really isn't a great compromise, because it does
as you say have too many things in it.  The original samba4 package
sharded things into a pile of tiny pieces:

https://packages.debian.org/source/oldoldstable/samba4

However, that wouldn't fix the issue, as while libwbclient is a
versioned library that will have a stable .so path on disk and a so
with a stable symbol version, winbind-client (wb_common.c) is not
(because private_library=True).

I see three options:
- We could put winbind-client into the same package as nss_winbind and
pam_winbind.  I'm not sure, absent atomic FS operations how you get the
library to install at exactly the right moment however.
- Static linking (which is what the autoconf build did, for reference).
- Putting the samba version into the on-disc library filename (like we
do/did with a -samba4 suffix) and somehow arrange that these not be
removed until after the new pam and nss libs are installed.

What can we assume about a pam or nss module being loaded?  Will the
symbols be resolved at dlopen() time, so we just need to add the
libraries first, replace the pam/nss modules and then remove the old
libs, or is there still a race no matter what due to lazy symbol
resolving?

The challenge with static linking is static data is no longer shared. 
That will mean one more pipe open to winbind in a process that is using
pam_winbind and nss_winbind.  

We however need to check the winbind_destruct is being run at module
unload (aa8d91ae8e6b4b813c0479f09be9e090aff047a9) and ensure we don't
link wb_common in to pam_winbind twice via libwbclient and your new
winbind-client-static, as that would mean yet another pipe. 

Finally, yes, there is a strict versioned dependency between the
winbind client library and the server.  If we, typically during major
upgrades, change the winbindd pipe protocol, we bump a version number
that is asserted, not negotiated.  Anyone still running the old code
after winbindd restarts will be very unhappy, and anyone running new
code against the old winbind will similarly be upset. 

This is all a little less than ideal, and I wish I had a good solution.

I hope we can keep discussing it, and perhaps others here have some
ideas.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba