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

T

timmmay

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:
Code: 
$ 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! :)
 
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
of the permissions associated with all ``group'' ACL entries in the
resulting ACL.

Traditional POSIX interfaces acting on file system object modes have mod-
ified semantics in the presence of POSIX.1e extended ACLs. When a mask
entry is present on the access ACL of an object, the mask entry is sub-
stituted for the group bits; this occurs in programs such as stat(1) or
ls(1). When the mode is modified on an object that has a mask entry, the
changes applied to the group bits will actually be applied to the mask
entry. These semantics provide for greater application compatibility:
applications modifying the mode instead of the ACL will see conservative
behavior, limiting the effective rights granted by all of the additional
user and group entries; this occurs in programs such as chmod(1).
Click to expand...

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 u:peter: 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... :\)

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

or

Code: 
# 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 u:peter back to read (?).
 
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.
 
You must log in or register to reply here.
Back
Top