frank2 at fjl.co.uk
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 fjl.co.uk>
>> 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
Any ideas anyone?
More information about the freebsd-questions