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

[Ivo De Decker]

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.

Any thoughts, comments?

> Or in the alternate, propose such changes upstream. 

Moving the files upstream would inflict all this pain on other distributions,
so someone would still have to sort this all out.


Cheers,

Ivo