I don't really understand what Access Control Lists are or how they differ much from the current file system permissions setup currently in Panther.
When Steve announced this at WWDC '04 the audience seemed very happy. What is it? And what features does it bring?
Mike
It was already said above. The ACLs make finer, more detailed permissions possible. In the old permissions style, you could have a single user as an owner of the file and single group as group the file belongs to. You could define permissions (read, write, execute) to each of these 3 entities.
With ACLs, you can have pretty much any number of owners of a file or any number of groups the file belongs to. For example, you can make a file unreadable in general and read-only for one group of users and read/write for another group of users - a task which was hardly possible now.
ACLs require both kernel support and support in the userland applications. Kernel support is probably fairly straightforward. Well, actually, maybe not so straightforward depending on how amenable HFS+ is to ACLs.
However, updating all the commmand-line and GUI tools, as well as any frameworks or other-more-than-bare-UNIX APIs to support ACLs is a lot of work.
Well, actually, no.
Quote:
The POSIX.6 defined access control list has 3 mandatory entries: an owner entry (called the file owner class), an owner group entry (called the file group class), and a world entry. This allows the three entries of the permission bit mechanism (owner, group, and other) to also be considered an ACL, and hence, compatible with the POSIX.6 specified ACL interfaces. Calls made to modify these ACL entries will also modify the corresponding file permission bits. Likewise, calls made to modify the file permission bits will also modify the corresponding ACL entries. This is intended to support backward compatibility with the large pool of existing applications that use the interfaces to the file permission bit mechanism.
Unless by "support" he meant "fully support." The backward compatibility is certainly welcome, but there's no particular reason to be satisfied with that. Fully ACL-savvy command-line tools would be terrific and useful feature, and also a significant amount of work.
Comments
I don't really understand what Access Control Lists are or how they differ much from the current file system permissions setup currently in Panther.
When Steve announced this at WWDC '04 the audience seemed very happy. What is it? And what features does it bring?
Mike
Originally posted by MPMoriarty
I have a question, though...
I don't really understand what Access Control Lists are or how they differ much from the current file system permissions setup currently in Panther.
When Steve announced this at WWDC '04 the audience seemed very happy. What is it? And what features does it bring?
Mike
It was already said above. The ACLs make finer, more detailed permissions possible. In the old permissions style, you could have a single user as an owner of the file and single group as group the file belongs to. You could define permissions (read, write, execute) to each of these 3 entities.
With ACLs, you can have pretty much any number of owners of a file or any number of groups the file belongs to. For example, you can make a file unreadable in general and read-only for one group of users and read/write for another group of users - a task which was hardly possible now.
For more detail see
http://csrc.nist.gov/publications/ni...-7/node27.html
or
http://en.wikipedia.org/wiki/Access_Control_List
Originally posted by nguyenhm16
ACLs require both kernel support and support in the userland applications. Kernel support is probably fairly straightforward. Well, actually, maybe not so straightforward depending on how amenable HFS+ is to ACLs.
However, updating all the commmand-line and GUI tools, as well as any frameworks or other-more-than-bare-UNIX APIs to support ACLs is a lot of work.
Well, actually, no.
The POSIX.6 defined access control list has 3 mandatory entries: an owner entry (called the file owner class), an owner group entry (called the file group class), and a world entry. This allows the three entries of the permission bit mechanism (owner, group, and other) to also be considered an ACL, and hence, compatible with the POSIX.6 specified ACL interfaces. Calls made to modify these ACL entries will also modify the corresponding file permission bits. Likewise, calls made to modify the file permission bits will also modify the corresponding ACL entries. This is intended to support backward compatibility with the large pool of existing applications that use the interfaces to the file permission bit mechanism.
Source: http://csrc.nist.gov/publications/ni...-7/node27.html
Originally posted by zzen
Well, actually, no.
Unless by "support" he meant "fully support." The backward compatibility is certainly welcome, but there's no particular reason to be satisfied with that. Fully ACL-savvy command-line tools would be terrific and useful feature, and also a significant amount of work.