Hi Steve, On Fri, Nov 01, 2013 at 04:31:36PM -0700, Steve Langasek wrote: > On Fri, Nov 01, 2013 at 01:20:35PM +0100, Ivo De Decker wrote: > > With the conflicts, samba-libs can only be installed once the old packages > > (samba, winbind, samba-common-bin [for smbpasswd and net] and > > libpam-smbpass) are no longer present. During the upgrade, this means > > they will already be upgraded (on new installations, there is no issue). > > There is no race condition, however, as none of these new versions will > > work, because they are all linked against libraries in samba-libs, which > > don't exist yet. So smbd and winbind will not be running, and will be > > unable to run (even if the admin tries to start them). The pam module > > also fails silently (this doesn't prevent login). > > This doesn't prevent login *in the default configuration*. You cannot > assume that the pam module is only being used via the stock pam profile - if > someone has configured their machine to use pam_smbpass as the primary login > method, this will break horribly.
I added the code from samba-libs.preinst to libpam-smbpass.preinst as well. Given that Jelmer convinced me yesterday to add a link instead of doing a simple move, the code is idempotent, so it doesn't matter if it runs multiple times in multiple maintainer scripts. When the preinst fails, libpam-smbpass will not be upgraded, and the old version will stay on the system. In samba 3.6, libpam-smbpass was self-contained and didn't need any shared libraries from other samba packages. This means that the old libpam-smbpass module will keep working, even when the upgrade fails: users are still able to login to pam-enabled services (like ssh) using credentials that are only stored in passdb.tdb. The only scenario where this is relevant, is when the tdb-files in /var/lib/samba/private already exist before the upgrade. This is only possible if we broke something in some older version of samba (I still haven't found any evidence of anything referencing /var/lib/samba/private in our old packages). In that case, the only thing we can do is fail with a clear message, instead of silently using the wrong user data. With these latest changes, the pam module will keep working, even in this case. That said, given that a race condition during the upgrade is easily reproducible, I am pretty convinced that the problem in the original submission of this bug was caused by such a race condition. That case should be fixed by the earlier changes. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
