[Pkg-samba-maint] Bug#726472: Bug#726472: share passwords not working after upgrade from samba3

[Ivo De Decker]

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