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

[Jelmer Vernooij]

On Mon, Oct 28, 2013 at 10:00:12PM +0100, Ivo De Decker wrote:
> Hi,
> 
> On Mon, Oct 21, 2013 at 10:37:49PM +1300, Andrew Bartlett wrote:
> > > Ok.  I think we need to undo this /var/lib/samba/private nonsense.  It is a
> > > pointless and imperfect migration (as shown by this bug report), and the
> > > only rationale upstream ever gave for keeping these files in a separate
> > > "private" directory is some stupid and ancient target OS that couldn't
> > > properly set per-file permissions.  Debian users have been using
> > > /var/lib/samba exclusively for the better part of a decade; migrating to
> > > this private/ directory adds no value for our users.
> > 
> > In the alternate, the only reason this happened now is because we are
> > finally having the Debian packages follow where upstream has decided to
> > put the files.  Having different packages moving files around to
> > different places only increases user confusion, and creates 'only on
> > Debian' bugs.  
> > 
> > For example, a significant number of issues came about as folks tried to
> > divine if a particular TDB was short, medium or long-term, when no such
> > separation existed in the code. 
> > 
> > We (upstream) have gone to significant effort to integrate the FHS
> > changes that have been proposed via Debian, I can only ask that having
> > got to a mutually agreed state, that Debian not change it again, having
> > once more Debian packages special and different. 
> 
> I had a long talk with Jelmer yesterday about this bug. Here are a number of
> considerations from that discussion:
> 
> 
> First of all, it certainly isn't clear that the issue is caused by a mistake
> in unstable some time ago. I haven't been able to find any indication for that
> (yet) in any of the samba versions available on snapshot.debian.org. We've
> been using /etc/samba as private dir from the first 3.2 upload to the last 3.6
> upload and there is no apparent usage of /var/lib/samba/private anywhere in
> the code of any of these versions.
> 
> It is quite possible that the issue is triggered by a race condition in the
> tdb-handling (especially for passdb.tdb), which can result in the creation of
> the wrong tdb file during the upgrade, which messes up our move. This could be
> caused by the usage of the 'smbpasswd' command or the pam-smbpass pam module.
> I haven't had the time yet to create a situation where I can trigger the race
> condition.
> 
> There are a number of ways to work around these possible race conditions
> during at the time of the move. An incomplete list of ideas (some of these
> would have to be combined to get to a complete fix):
> 
> - Patch the passdb tdb module to do the move, instead of having it in
>   samba.postinst. This isn't completely unprecedented, as the move of
>   MACHINE.SID was supported by the samba code.
> 
> - Track the fact that the move was done, by adding some field to the new tdb
>   file. This might cause issues in tools that don't handle unknown fields. The
>   samba4 upgrade script might be one of those.
> 
> - Track the fact that the move was done, by making sure the old tdb can't be
>   used anymore. This could be done by changing the version number of the old
>   tdb to something non-existent.
> 
> - Do some kind of merge of both tdb files, if they both exist.
> 
> - When both tdb files exist, have a debconf question that gives some
>   information about both (eg number of users), and ask the user to choose
>   between them.
> 
> Any decent implementation will require some careful planning and probably
> quite some discussion as well. It is clear that the new samba 4.x packages
> provide a nice step forward compared to the samba 3.6 packages, and these
> changes shouldn't be blocked by this problem. Therefore we are proposing to
> postpone this move for now.
> 
> Moving the private dir to /var/lib/samba would cause an issue with the files
> kept by samba4 in /var/lib/samba/private. So the only obvious way forward
> would be to have a new version of our previous patch, which moves the 4
> affected files back to /var/lib/samba. I really regret having to propose this,
> as I very much would like to avoid reintroducing a patch like that, but at
> this point, I don't really see any other short term options.

> So the proposal is to reintroduce something like the old patch, and try to get
> that version into shape for testing/jessie. After that, we can figure out how
> to get this move done the right way.

An alternative solution might be to just move those four files that
already existed back in 3.x back from privatedir to sysstatedir and
to not revert the entire move to privatedir.

That'll also cause some confusion though, as those files will be in
sysstatedir on debian but in privatedir on other systems...

Cheers,

Jelmer