Skip to content

Changes ACL permission setting hints #3566

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Changes ACL permission setting hints #3566

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Feb 11, 2014

The default behavior of setfacl is to recalculate the ACL mask entry, unless a mask entry was explicitly given.

The default behavior of setfacl is to recalculate the ACL mask entry, unless a mask entry was explicitly given.
@weaverryan
Copy link
Member

Hey Michele!

Can you explain this a bit more? I'll admit that ACL is not my strongpoint, and I can read the setfacl manual that you quoted, but I'm still not really sure what this would change :). Did the original command cause you problems? Was it doing something extra it didn't need to?

Thanks!

@cordoval
Copy link
Contributor

I think the explanation falls into these paragraphs:

 AUTOMATICALLY CREATED ENTRIES
       Initially,  files  and  directories  contain  only  the  three base ACL
       entries for the owner, the group, and others. There are some rules that
       need to be satisfied in order for an ACL to be valid:

       *   The three base entries cannot be removed. There must be exactly one
           entry of each of these base entry types.

       *   Whenever an ACL contains named user entries or named group objects,
           it must also contain an effective rights mask.

       *   Whenever an ACL contains any Default ACL entries, the three Default
           ACL base entries (default owner, default group, and default others)
           must also exist.

       *   Whenever  a  Default ACL contains named user entries or named group
           objects, it must also contain a default effective rights mask.

       To help the user ensure  these  rules,  setfacl  creates  entries  from
       existing entries under the following conditions:

       *   If  an  ACL contains named user or named group entries, and no mask
           entry exists, a mask entry containing the same permissions  as  the
           group  entry is created. Unless the -n option is given, the permis-
           sions of the mask entry are further adjusted to include  the  union
           of  all  permissions affected by the mask entry. (See the -n option
           description).

       *   If a Default ACL entry is created, and the Default ACL contains  no
           owner, owning group, or others entry, a copy of the ACL owner, own-
           ing group, or others entry is added to the Default ACL.

       *   If a Default  ACL  contains  named  user  entries  or  named  group
           entries, and no mask entry exists, a mask entry containing the same
           permissions as the default Default  ACL’s  group  entry  is  added.
           Unless  the  -n  option is given, the permissions of the mask entry
           are further adjusted to inclu  de  the  union  of  all  permissions
           affected by the mask entry. (See the -n option description).

so in a way trying to avoid automatic adjustment of the effective permissions of the mask. But yeah we need an expert opinion.

@ghost
Copy link
Author

ghost commented Feb 27, 2014

If the main goal of documentation ACL hints is to prepare directories to work in any condition, it should be better to have ACL winning on mask options.
You can say that anything in the involved directories at first installation time should not be covered by particular mask settings, but what if something in our applications creates files at runtime with particular ones?

@cordoval
Copy link
Contributor

yes I agree, we should merge this

@ghost
Copy link
Author

ghost commented Mar 4, 2014

@weaverryan an example of software that would write umasks while running is sqlite, so it could happen to have resources covered by an umask into the cache directory.
This is an example scenario where I would prefer to have an ACL setted to ignore it.

@ghost
Copy link
Author

ghost commented Mar 10, 2014

Using everyday a Debian derivate distro instead of Appleish products mwould make ACL problems more evident.

@weaverryan
Copy link
Member

Thanks guys! I'll admit, I still don't really understand what this does, but I'm also pretty sure that's due to my lack of knowledge about the ACL's and masks themselves (but you seem to understand well). Anways, thanks for the change! :)

weaverryan added a commit that referenced this pull request Mar 10, 2014
This PR was submitted for the master branch but it was merged into the 2.3 branch instead (closes #3566).

Discussion
----------

Changes ACL permission setting hints

The default behavior of setfacl is to recalculate the ACL mask entry, unless a mask entry was explicitly given.

Commits
-------

4480eff Changes ACL permission setting hints
@weaverryan weaverryan closed this Mar 10, 2014
@ghost
Copy link
Author

ghost commented Mar 10, 2014

Thanks to you for the effort on documentation!

@sr972
Copy link

sr972 commented Mar 15, 2014

Hi,

just tried the new way on a Linux Mint 16 sytem using the -n parameter. In my system leads to an effective: r-x for both, www-data ($APACHEUSER) and the 'whoami'.

I deleted all acl rights but the standard for owner, group, other and retried. Always lead to #effective: r-x. As soon as i deleted the acl rights and used it without the -n parameter it worked like a charm. So there seem to be differences in the systems maybe?

When i used the commands via C&P before, it always worked for me on Debian 6/7 and Ubuntu 12.04 LTS.

Maybe there should be an additional hint?

EDIT (finally after serveral c&p errors):

sr972@main /var/www $ setfacl -bk app/cache
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
group::r-x
other::r-x

sr972@main /var/www $ sudo setfacl -Rn -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ sudo setfacl -dRn -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
user:www-data:rwx       #effective:r-x
user:sr972:rwx          #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:www-data:rwx   #effective:r-x
default:user:sr972:rwx      #effective:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

sr972@main /var/www $ setfacl -bk app/cache
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
group::r-x
other::r-x

sr972@main /var/www $ sudo setfacl -R -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ sudo setfacl -dR -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
sr972@main /var/www $ getfacl app/cache
# file: app/cache
# owner: sr972
# group: sr972
user::rwx
user:www-data:rwx
user:sr972:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:www-data:rwx
default:user:sr972:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

@ghost
Copy link
Author

ghost commented Mar 16, 2014

Wich version of ACL are you using?

@ghost
Copy link
Author

ghost commented Mar 16, 2014

@sr972 I think you should make another pull request and move the discussion on that one!

@weaverryan
Copy link
Member

Yes @sr972 - can you open up a pull request with the changes and details? The truth is, this command seems to be very difficult to get right, and it's very very technical. So, if it's not working for you, it's likely not working for others, and I'd love to have a PR where we can discuss it (so it doesn't get lost!).

Thanks!

@weaverryan
Copy link
Member

See #3712 - there is indeed now a problem with this command

@sargath
Copy link

sargath commented Mar 24, 2014

Exactly for me on Linux, setfacl works as usual with -dR and -d option only... without -n option, because that cause rights problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants