Messages in this thread | | | Date | Thu, 4 Feb 1999 21:12:30 -0800 (PST) | From | Tim Smith <> | Subject | Re: linux capabilities and ACLs |
| |
On Thu, 4 Feb 1999, Albert D. Cahalan wrote: > Good. POSIX ACLs are awful. Somebody stop the ext2 developers before > it is too late. With a tiny bit of thought, it should be obvious > that the inheritance system is broken. ACL systems that are much better > include those of NT, Netware, Digital Unix...
I think the TOPS-10 system was conceptually much better, although the implementation suffered from problems (mainly because it was a gross hack). The basic idea is that the ACLs are *not* stored as some sort of extended attribute of the files, like they are on most other systems. Instead, the ACLs for a user's files are in a single file (I don't recall if TOPS-10 actually did one file per user, or one per directory per user).
Basically, this file contains a list of descriptions of allowed and non-allowed accesses, with wildcarding allowed. You could base things on the name of the file (including path), the user and group of the person trying the access, the type of accesses they were requesting, and what program was trying the access.
The system only checked the access file if the access was not otherwise allowed.
This doesn't conveniently do everything convention "ACL's as extended attributes" do, but if you are reasonably organized in how you store your files (e.g., you tend to put things with the same desired access rules in the same directory), it works great.
There are two big advantages compared to the "ACL's as extended attributes" approach.
1. No modification is needed to the format of any filesystem to support this.
2. No modification is needed to existing utilities.
On TOPS-10, the access file was just a text file, and the wildcarding was the same kind used for filename matching. I think on a Linux implementation, I'd prefer full regular expressions, and probably for speed have the text file compiled into a binary file.
I think this kind of system should be considered for Linux. I can see some problems with hard links, but it might be a nice way to provide most of the benefits of ACLs with almost none of the disadvantages of the usual approach. If a Linux implementation kept the TOPS-10 behaviour of only checking the access file on accesses that would otherwise fail, then there should be minimal backward compatibility issues (the only thing that comes to mind offhand would be programs that try to figure out on their own if something is allowed, rather than just trying and letting the kernel tell them).
--Tim Smith
ps: the big problem with the TOPS-10 implementation was that the access check was done by a daemon outside the kernel. When an access failed, the kernel send a message to FILDAE describing the request, and FILDAE told the kernel if it was to be allowed. People manage to find and exploit bugs in the communication between FILDAE and the kernel to get them out of sync.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |