Reassign file server related bugs up to tridge.

I can reproduce this with 3.5.1 as well.

Adding information here since it seems to be the same bug.

ACL inheritance cannot be disabled if the ACLs on the current object are identical to the ACLs of the parent object. If they are different from the ACLs of the parent object, inheritance _can_ be disabled.

Created attachment 5588 [details]
Level 10 debug log during uninherit, copy and apply of ACLs on a file

This is a level 10 debug log during manipulation of ACLs with the windows XP security editor. Actions were:
- Uncheck "Inherit ACLs" checkbox
- Answer "Copy" to the popup with the question about what to do with the permission entries (from choices Copy|Remove|Cancel)
--> The "Inherit ACLs" checkbox is now unchecked
- Click "Apply"
--> The "Inherit ACLs" checkbox is now checked again

Created attachment 5589 [details]
Level 10 debug log during uninherit, copy, edit and apply of ACLs on a file

This is a level 10 debug log during manipulation of ACLs with the windows XP security editor. Actions were:
- Uncheck "Inherit ACLs" checkbox
- Answer "Copy" to the popup with the question about what to do with the permission entries (from choices Copy|Remove|Cancel)
--> The "Inherit ACLs" checkbox is now unchecked
- Edit one of the ACLs, change "Full Control" into something else
- Click "Apply"
--> The "Inherit ACLs" checkbox remains unchecked

Surprisingly, if you have uninherited ACL's and you change them so they are identical to the ACL's of the parent object, the Inheritance checkbox gets checked again.

Created attachment 5590 [details]
Output of testparm -sv

Samba configuration (3.5.1)

ekacnet, I've tried to reproduce this - and well, this is not a bug.

Samba 4 has the following code in "pvfs_acl_set":
>        /* we avoid saving if the sd is the same. This means when clients
>           copy files and end up copying the default sd that we don't
>           needlessly use xattrs */
>        if (!security_descriptor_equal(sd, &orig_sd) && pvfs->acl_ops) {
>                status = pvfs->acl_ops->acl_save(pvfs, name, fd, sd);
>        }

That means the following: if you just untick the flag "inherited from parent" and click on "Ok" or "Apply" the old and the new SDs are still the same and this won't be saved as the comment states.

But if you untick and change the descriptor and then click "Okay" the SD will be duplicated, changed and the inheritance removed.

So no bug here - s4 just doesn't want to waste space for duplicated SDs.

Matthias,

Have we checked the behavior on a windows with a windows server ?
And sorry to say it, it's a bug as I'm pretty sure that windows don't do this and we can face the problem in this particular test case:

we have \\server\share\dir1\dir2

dir2 inherit the acls from dir1, let's suppose that the admin wants to change the acls of dir1 but not on dir2 and start by making them non inheritable on dir2 then change them on dir1.

If we implicitly re-set the acls to be inheritable, then when you change the acls on dir1, acls on dir2 will be changed if you unset inheritable then even if at a given moment acls on dir1 and dir2 are the same when you change dir1, dir2 won't be changed

Then please try to comment out the mentioned "if" and let always the "acl_save" command to be executed. I bet that it starts working as expected.

Hi Matthias,

I can reproduce this with 3.5.x as well. Please let me know if you want a separate bug report for this problem in samba3.

Regards,

roel

Yes please (for the 3.5.6 bug). Note I'll probably ask you to test with the new jumbo-acl patch that will be in 3.5.7 to see if this is fixed.
Jeremy.

Opened a new bug for the same issue in samba3: https://bugzilla.samba.org/show_bug.cgi?id=7812