Date: Tue, 06 Feb 2018 17:25:00 +0000 From: Frank Leonhardt <frank2@fjl.co.uk> To: freebsd-questions@freebsd.org Subject: Re: ACL trouble Message-ID: <8918ae958f8b4bbd078c7a0fc6ea3505@roundcube.fjl.org.uk> In-Reply-To: <B942A38C-7E37-451A-825A-13117E1E5DA4@kreme.com> References: <634f440c0ab99f5c49bf592a6e796789@roundcube.fjl.org.uk> <B942A38C-7E37-451A-825A-13117E1E5DA4@kreme.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-02-05 18:46, LuKreme wrote: > On Feb 5, 2018, at 08:16, Frank Leonhardt <freebsd-doc@fjl.co.uk> > 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8918ae958f8b4bbd078c7a0fc6ea3505>