On Sat, 2013-11-02 at 11:27 +0100, Ivo De Decker wrote: > Hi Steve, > 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.
Thank you so much for you diligent attention to this difficult problem. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
