ACLs and upgrades

[Gémes Géza]

Hi,
> 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
>
First of all: thank you for the explanation of it.
Second: is it to be expected, that the ACL upgrade (correct) 
functionality be brought to the dbcheck tool eventually?

Thank you

Cheers

Geza Gemes