ACLs and upgrades

[Andrew Bartlett]

On Mon, 2013-03-18 at 21:29 +0100, Marc Muehlfeld wrote:
> Hello,
> 
> Am 06.03.2013 10:54, schrieb Karolin Seeger:
> > Samba 4.0.4 is scheduled for Tuesday, March 19.
> 
> Can you please include a small info in the release notes (or the wiki), 
> how users running <= 4.0.2 can update (or if it's suggested to stay at 
> their version), because of the ACL changes in 4.0.3 and later.
> 
> 
> 
> The release notes of 4.0.3 said:
> 
>  > For more details concerning the ACL problem with delegation of
>  > privileges and deletion of accounts over LDAP interface (bugs #8909
>  > and #9267) regarding upgrades from older 4.0.x versions, please see
>  >
>  >     http://wiki.samba.org/index.php/Samba_AD_DC_HOWTO#Upgrading
>  >
>  > which will be filled with details once we have worked out an upgrade
>  > strategy.
> 
> but yet there isn't an information if <= 4.0.2 users can upgrade without 
> lossing existing ACLs (like for delegations).

This is a sorry story of unexpected complexity and unexpected
distractions and poor communication.

The first thing I want to say is that it always has been safe to upgrade
to Samba 4.0.3, as it will be to upgrade to our next minor releases.
There is no action *required* on upgrade, but we were hoping to finally
remove the need to set 'acl:read=false' from the smb.conf by getting the
ACLs right, once and for all. 

What happened was this:  Running up to the 4.0.3 release, we thought
that we could simply bring the samba_upgradeprovision tool out of
retirement, that some small changes so it knew about some more of the
ACLs we had changed would be sufficient. 

Then we got your comments on
https://bugzilla.samba.org/show_bug.cgi?id=9267 and I started to add
tests not only of our ability to successfully run the upgrade code, but
to determine if the result was actually correct.  This opened a can of
worms that we are still not to the bottom of.

Sadly, I found a number of issues with the samba_upgradeprovision tool,
specifically around resetting security descriptors.  Depending on the
mode it was run in, it would reset all security descriptors, or even add
extra objects (DNS partition pointers) to the directory.

samba_upgradeprovision attempts to be smart about when it is allowed to
update an object, based on a note we made at provision time.  However,
if it detects that the provision was not made by an alpha release
matching the pattern alphaXX (including beta, and final releases), it
instead made a much more dumb assessment.  I think in your situation
this is why a lot of 'changed' security descriptors were still reset.

All this made my confidence in this tool, and the idea of making a
widespread recommendation to use it dwindle, so we have removed it from
our set of installed binaries in master, and I'm asking that the same be
done in 4.0.x.

Finally, in your situation we would still be stuck, even if
samba_upgradeprovision worked perfectly, as it would notice your changed
CN=Computers SD, and not update it!

So, where does this leave us?  At this point the only option I can
sensibly consider is providing a tool to forcibly reset the well known
security descriptors (including removing your delegation on
cn=computers), but to add it to dbcheck, to run in that interactive
tool.  That way, you can choose to keep your delegation (but have the
rest of the SD be incorrect), or accept the reset (and re-add any
delegation later). 

Finally, we had the unexpected distraction of the world-writeable files
that you will have seen the commit for.  That has given me a little more
time to prepare a solution here, but has also taken up a great deal of
time. 

All of this is rather unsatisfactory for our users, and as a developer
quite unsatisfying, but I would rather be upfront with our issues than
pretend this is all perfectly OK. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org