>>>>> "R" == R Joseph Wright <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>