ACLs: Merits and Demerits
On 18 Mar 2000 12:50:42 +1100, the world broke into rejoicing as
Brian May <bam@debian.org> said:
> >>>>> "R" == R Joseph Wright <rjoseph@nwlink.com> writes:
> >> Personally, I think this is hopelessly out-of-date, and the
> >> sooner we move to ACLs, the better.
>
> R> Can someone explain a bit how ACLs work?
>
> It is just the same as current systems, except the structure is
> flexible, and can different for each file.
Flexibility has its ups and downs...
> For instance, currently this is how it is currently done.
>
> (early entries receive priority)
>
> For a file with following permissions:
>
> rwxrw-r-- bam users
>
> this maps into three rules.
>
> 1. userid==bam => access=rwx
> 2. groupid==users => access=rw-
> 3. default => access=r--
>
> This is very inflexible, as only three fixed rules can be
> provided. Note, the hurd changes this somewhat to for non-logined
> users, by adding a new 4th rule somewhere, perhaps (not sure) like
> this:
>
> 1. no userid => access=---
> 2. userid==bam => access=rwx
> 3. groupid==users => access=rw-
> 4. default => access=r--
>
> ACLs will allow you to setup different rules for each file, without
> being fixed to any given structure.
>
> So, for instance, if I wanted to let a friend access a copy of
> my file, I could gives rules like:
>
> 1. userid==bam => access=rwx
> 2. userid==friend1 => access=rwx
> 3. userid==friend2 => access=r-x
> 4. default => access=r--
>
> (you could argue that these rules are a bit stupid, ie denying world
> execute permission, but allowing friend2 to execute. Still, this
> might be useful for SetUid programs).
>
> My main concern with ACLs seems to be the large number of
> implementations that exist, probably all of them will be incompatible
> with each other. AFS, SunOs, EXT2, and NTFS all support ACLs to some
> degree.
>
> Note: I have never really played around with actually implementations
> of ACL, so details of what I have said may not always be true. For
> instance, ACLs under AFS control all files within a directory, and
> cannot have different ACLs for different files within the directory.
May I suggest a couple of "counterpoint" points?
--> Flexibility that you have to expend considerable effort to
configure is hardly a gain.
--> You correctly observe that there are a bunch of implementations of
ACLs, and no particular user interface has proven dominant. This
is not unlike the GUI situation where UI's haven't been so good as
to dominate on technical grounds (without billion dollar marketing
budgets...)
--> Having ACLs requires further planning of security policy, both to:
a) Apply suitable ACLs to files, and
b) Apply suitable policies behind those ACLs to establish what is
to be permissible.
As has been observed elsewhere in the threads, ACLs aren't necessarily
even the answer to the overall set of security problems. They may be
the "Holy Grail" to some, but it's only at the C2 level of TPEP where
they appear to be formally mandated.
As a Completely Different Thought (which I periodically bring up), it
might be worth looking back into the past; TOPS-10 had an ACL system
controlled by a daemon called FILDAE where, rather than sticking the
ACL data into nodes on the filesystem, it centralized them into a set
of patterns in a file.
Approach: If accesses fail, due to the "usual" ugo/GECOS fields
indicating NO access, the kernel would send a message to FILDAE asking
if the ACLs would permit access based on the rule set. If so, then
FILDAE would tell the kernel to give access.
This seems to be a rather Hurd-like approach; with Hurd, it is quite
natural to add a daemon of this sort...
--
Rules of the Evil Overlord #91. "When I create a multimedia
presentation of my plan designed so that my five-year-old advisor can
easily understand the details, I will not label the disk "Project
Overlord" and leave it lying on top of my desk."
<http://www.eviloverlord.com/lists/overlord.html>
cbbrowne@hex.net - <http://www.ntlug.org/~cbbrowne/lsf.html>
Reply to: