setfacl potentially not working anymore

[weaverryan]

After #3566, the setfacl command may not be working.

I was talking with @umpirsky - the current command did not work for him suddenly, but removing the -n added in #3566 fixed it.

I don't know enough about ACL's to really understand what difference the flag makes.

[xabbuh]

May the problem be related to the ACL version or to the filesystem type being used? I can't reproduce the issue with 2.2.51 on an ext4 filesystem.

What do you use, @umpirsky?

[docteurklein]

I don't know a lot neither, but from what I understand in the man page:

 -n, --no-mask
           Do not recalculate the effective rights mask. The default behavior of setfacl is to recalculate the ACL mask entry, unless
           a mask entry was explicitly given.  The mask entry is set to the union of all permissions of the  owning  group,  and  all
           named user and group entries. (These are exactly the entries affected by the mask entry).

the default behavior is to recalculate the mask entry (union of (owner group + named user + group entries) permissions).

-n would block this behavior unless you explicitly set a mask, what we do!

So to my mind, -n should have no effect.

Apparently it's not :)

Edit: With -n, the permissions of the mask entry are not further adjusted to include the union of all permissions affected by the mask entry.

[umpirsky]

@xabbuh setfacl 2.2.52 on ext4.

[sr972]

I have acl 2.2.51-8 on Debian 3.2.46-1+deb7u1.

I think the problem is caused, when user and group are not the same. If there is no permission definied, in my case, there is a user::rwx and group::r-x aswell as other::r-x permission.

So if user and group won't match, the group write permission is denied because of the missing write privileg in the group. It looks like, that not permission but deny wins.

And if you put a -n parameter into the setfacl statement, then there will be no recalculation of the (effectiv) rights. So there is still a deny coming from the group.

Just my 2 cents.

[weaverryan]

Oh boy, so what do we think on this? Do we sometimes need the -n and sometimes not? Anyone know a lot about this?

[sr972]

As far as i know, i never heard about problems with the old command line w/o the -n parameter. So the answer is fairly easy. Undo the change, remove the -n parameter.

Or are there any know issues when not using -n?

[xabbuh]

Maybe @MicheleOnGit who introduced the parameter can explain his reasons for doing so?

Well, on some SF2 projects I use a test suite that both runs WebTestCase tests from command line and selenium ones. To make the build process faster I use also sqlite database in test env.
Then the first test of the suite that run will create the phisical file containing the DB, I use to put my DB in the cache directory.
If the first test runs as shell (WebTestCase ones), that file will be created with certain umask settings, associated to the user that launched the test suite.
If the next test is one running in selenium the user that will try to access that file is now belonging to the www-data group and despite the ACL settings UMASK directives will be strongest until the -n parameter is used. This is for linux mint 15.

I think it should be tested with different acl versions and\or file systems.

[weaverryan]

I proposed this solution until we know more: #3716 (comment)

Thanks for the participation everyone!

I agree, is the best option, and I'm sorry if I have propoused something that was so dependent on my platform settings maybe. Thank you all guys.