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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584485 Title: Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
