# Having trouble keeping ACL's from messing with real permissions.



## timmmay (Nov 20, 2012)

I've had some trouble with ACL's. I am new to them and relatively unfamiliar. Tutorials and guides make it look like a one command hassle-free process. For me, this was not the case. Any time that I try so give a user or group new permissions for a file, seemingly unrelated real permissions are changed.
For Example:

```
$ touch example

$ ll example
-rw-r--r--  1 tim  tim  - 0 Nov 20 10:07 example

$ getfacl example
# file: example
# owner: tim
# group: tim
user::rw-
group::r--
other::r--

$ setfacl -m u:peter:rw example

$ getfacl example
# file: example
# owner: tim
# group: tim
user::rw-
user:peter:rw-
group::r--
mask::rw-
other::r--

$ ll example # Everything from getfacl looks ok, but why the change to group?
-rw-rw-r--+ 1 tim  tim  - 0 Nov 20 10:07 example
```

I felt that I must be missing something both essential and basic. After looking around for a while, I still couldn't find any guides that even touched on ACLs except to teach the basic setfacl, getfacl (and without addressing their affects on real permissions). So, disregarding any fears of being labeled noobish or ignorant (neither entirely inaccurate), I headed down to the FreeBSD Forums! Thank ye kindly!


----------



## timmmay (Nov 20, 2012)

Sorry to post twice, but I would also like to request an ACL guide/tutorial if at all possible.


----------



## usdmatt (Nov 20, 2012)

Disclaimer: I've never used acls and also find them awkward, especially when mixed with the 'normal' permissions.

The following from the setfacl man page seems to be appropriate though:



> A ``mask'' ACL entry is required on a file with any ACL entries other
> than the default ``user'', ``group'', and ``other'' ACL entries.  If the
> -n option is not specified and no ``mask'' ACL entry was specified, the
> setfacl utility will apply a ``mask'' ACL entry consisting of the union
> ...



So basically, there has to be a 'mask' entry as soon as you add permissions other than the standard user/group/other. This mask is duplicated in the unix group permissions and is (somehow) used as a mask on top of the other permissions when the unix mode is changed although it's not clear which acls it gets used on. This helps compatibility seeing as some things will support the acls and some won't.

I don't get why it's put a mask of rw on yours though. The man page says it's a union of all the 'group' acls, but you only have one group acl, and it's only read. I can only guess there's some other complexity about the whole process that the man page hasn't covered. 
I've got a feeling it includes the user permissions in the mask as well - for users other than the owner. (So it's merging the permissions for ueter: rw & group:: r and setting that as the mask). That way, if you remove 'write' permission for the group with chmod, that will remove write from the mask, and also any other group acls, and any user: acls. This will give write back only to the owner in your case, which is what you'd expect if you were not aware of acls.

Someone else may have to confirm all this...

Have you tried the following:
(I haven't, my only test system available is ZFS and that has NFSv4 acls which appear to be completely different again... :\)


```
# touch example
# setfacl -m m:r,u:peter:rw example
```

or


```
# touch example
# setfacl -m u:peter:rw example
# setfacl -m m:r -n example
```

The -n should tell it not to recalculate any ACLs based on the mask, which may otherwise set ueter back to read (?).


----------



## timmmay (Nov 21, 2012)

This certainly seems to be a good pace or two the right direction, and with any luck I'll figure out the finer detail within the hour. Thank you very much.


----------

