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

[Jelmer Vernooij]

On Tue, Oct 29, 2013 at 10:10:58AM +1300, Andrew Bartlett wrote:
> On Mon, 2013-10-28 at 22:00 +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.
> > 
> > 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.
> 
> I strongly oppose both proposals.  The upgrade to Samba 4.0 is the time
> to correct this silly business of having files in different paths to
> what upstream has, rightly or wrongly, chosen.  

What approach would you suggest for a race-free migration of
existing files to privatedir?

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20131029/2fb8cd10/attachment-0001.sig>