ACL trouble

Frank Leonhardt frank2 at
Tue Feb 6 17:25:06 UTC 2018

On 2018-02-05 18:46, LuKreme wrote:
> On Feb 5, 2018, at 08:16, Frank Leonhardt <freebsd-doc at> 
> wrote:
>> The problem with ACLs, as I understand them, is that the system will 
>> search through until it finds an "allow" condition and only return 
>> "deny" if it completely fails. In other words, Group1 OR Group2 = 
>> Allow. I want a condition that says Group1 AND Group2 = Allow.
> That is not my experience with ACLs in general, but I have not used
> them on FreeBSD.
> For example, on my machine I used to have a folder of movies that were
> world readable, but all the R and NC-17 movies isn’t eh folder were
> tagged with an ACL that meant the kids accounts could not read the
> files. They could see the file names because they could read the
> directory, but they could not play the movies.
> Similarly, I had a folder that was not accessible to them, they could
> see the name of the folder, but could not see the contents and because
> those files inherited the ACL of the folder even if they'd guessed at
> the name of a file, they would not have been able to access it.
> My understanding is that ACLs evaluate all the rules, and then fall
> through to the UNIX permission if nothing matches a rule.

What system was this? Windows? I remember OS/2 (now Windows NT) ACLs 
were somewhat different.

POSIX ACLs are as well defined as basic Unix ones, but even more 
mind-bending until it "clicks", and they don't work the way you 
understand. I don't think they've fully clicked with me. At least I hope 
not, because I want to do something clever with them and I can't see 
how. It very specifically DOES NOT evaluate any more rules once it has 
found a match.

Basically, POSIX systems try the ACL user/group after first trying the 
basic Unix ones (the precise order is defined but irrelevant here). The 
first "match" it finds ends the search and grants access. There is no 
"deny access" match; it's only denied once all the tests fail.

Except - consider the situation when the calling process belongs to more 
than one group. Oh joy! The file can also belong to more than one group. 
Quote: "If one of the group IDs of the process matches the owning group 
or any of the named group entries, but neither the owning group entry 
nor any of the matching named group entries contains the requested 
permissions, this determines that access is denied".

You only get to the above if you've failed to get an exact match on user 
or group permissions, and this comes BEFORE the Other permissions are 
considered. So it seems to be saying that you can block access to a 
group by setting the ACL one of the user's groups to "no entry". 
Everyone not in this group falls back on Other permissions.

If I've got this right, it looks like you could block access by creating 
a "poison" group and joining people to it, but at the expense of the 
rest-of-world access being open. Sounds like a bad idea.

I'm trying to get my head around utilising the final stage in the 
process, where the mask is used. It's giving me a headache thinking 
about it.

Any ideas anyone?

More information about the freebsd-questions mailing list