[Bug 1584485] Re: Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS

[Marc Deslauriers]

I don't believe the debdiffs provide a valid solution to this issue.
Here is an irc discussion with infinity where he presented a better
solution:

<mdeslaur> infinity: I'd appreciate your thoughts on the best way to address bug 1584485
<mdeslaur> infinity: that approach doesn't look sane to me, do you have any suggestions for something better?
<infinity> mdeslaur: The proposed fix is certainly not reasonable.  I'll ponder the problem over breakfast.
 mdeslaur: Is it a question of ABI breaks, or ABI additions?  It seems the real issue is bad dependencies between libnss-winbind and its deps.
<infinity> Oh, because samba-libs is a big blob os libraries that shouldn't be packaged together.
 Whee.
<mdeslaur> infinity: if the abi changes, running processes die because they're running with the old version of libnss-winbind
 infinity: I guess abi additions should be fine, but I'm not sure how careful samba preserves abi between versions
<infinity> mdeslaur: Running processes should be fine, it's new processes that explode miserably.  (Well, or running processes calling into NSS anew, but that's still "new", from my POV)
<infinity> mdeslaur: But yeah, the problem is clearly a lack of sane ABI versioning on "samba-libs" and, thus, incorrectly weak deps between libnss-winbind and samba-libs.
 mdeslaur: Doesn't look like something one can properly fix in an SRU, since the fix is to actually version the *#^)! libraries correctly.
<mdeslaur> oh, right, new processes in that specific case
<infinity> mdeslaur: But having samba-libs Break libnss-winbind << Binary-Version, and disable/reenable winbind on preinst/postinst would "work".  Though, gross.
<mdeslaur> I thought I saw a bug where existing processes were crashing because of an incompatibility with a newer winbind service
<infinity> Existing processes will also explode if they call into NSS fresh, NSS is effectively a dlopen().
<infinity> But yeah, I consider dlopen "new processes" from the POV of hunting library ABI issues. :P
 Otherwise my head hurts.
<infinity> Anyhow, any solution that halts upgrade with "we notice you have packages installed and you're actually using them correctly; please stop using them" is not sane.
 If it can be automated to disable/reenable, that's vaguely okay, though if their setup relies on winbind resolution working, there's a gap there where the world sucks.
 But better that than crashing, I suppose.
<mdeslaur> infinity: but what happens when an existing process is running with an old libnss-winbind, and the windbind package gets upgraded to a version that is not compatible with the old libnss-winbind?
 perhaps that's not a problematic scenario
<infinity> mdeslaur: After taking a walk, it occurs to me that in the absence of proper library versioning, the more robust solution might just be for nss-winbind and pam-winbind to be statically linked to samba-libs.
 mdeslaur: That would eliminate the problem, and have the added bonus of not having to pull in a massive samba-libs package just for the small bits that the nss/pam plugins need.
<mdeslaur> hrm, that does sound reasonable

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1584485

Title:
  Upgrading samba to latest security fixes together with winbind in
  nsswitch.conf can harm entire OS

Status in samba package in Ubuntu:
  In Progress

Bug description:
  [Impact]

  * Upgrading samba when using winbind as NSS service can break OS.
  * Probably not triggered if "compat" is BEFORE "winbind" in nsswitch.conf.
  * Huge impact due to big version different between winbind and libraries.

  [Test Case]

  * Comment #1 (to upgrade samba)

  [Regression Potential]

  * "preinst" and "postrm" maintainer scripts are acting only in "upgrade"
  * uninstalling packages and reinstalling would bypass this change

  [Other Info]

  * Original Bug Description:

  It was brought to my attention that, because of latest security fixes
  for samba:

  https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1577739

  samba (2:4.3.9+dfsg-0ubuntu0.14.04.1) trusty-security; urgency=medium
  samba (2:4.3.8+dfsg-0ubuntu0.14.04.2) trusty-security; urgency=medium
  samba (2:4.1.6+dfsg-1ubuntu2.14.04.13) trusty-security; urgency=medium

  when library symbols changed, a samba upgrade MAY jeopardize an entire
  Ubuntu OS installation IF /etc/nsswitch.conf uses winbind as a service
  (specially if used before compat mechanism).

  ----

  How to reproduce easily:

  $ cat /etc/nsswitch.conf
  passwd: winbind compat
  shadow: compat
  group: winbind compat

  (winbind is usually used after compat, in this case it was used
  before)

  to have samba version "4.1.6+dfsg-1ubuntu2.14.04.13" installed and do
  a:

  $ sudo apt-get update

  and FINALLY:

  https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/comments/1

  Leading into an unusable system in the following state:

  https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/comments/2

  ## state

  Workaround:

  DO REMOVE winbind from /etc/nsswitch.conf (and possibly from pam.d
  with "pam-auth-update") before ANY attempt of upgrading samba to
  latest version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/+subscriptions