Re: "Small" Bug - silly question again

[Brian May <bam@debian.org>]

>>>>> "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.

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.
-- 
Brian May <bam@debian.org>