(Illustration by Gaich Muramatsu)
On Tue, Feb 27, 2007 at 02:49:05PM +0100, Enrico Weigelt wrote: > And now some diferrent view: what does an unix permission > mean in ACL words ? Well, each file has an ACL with the > structure: > * 1. ownership: the one who's allowed to change the ACL > * 2. permissions for the one who owns the file > * 3. permissions for some group > * 4. permissions for the 'world'-group (all users) Coda ACLs are more course grained since they are per directory, and they are more fine grained since they separately allow or deny things like adding or removing an entry from a directory. Lets look at some ways that I've used directory ACLs. Maildir email delivery The mail delivery agent runs as a non-priviledged user and doesn't require setuid/setgid. It has a token to identify it as the 'mail-delivery' user to the system. My email is stored in maildir format, when new email arrives the delivery process writes it to folder/tmp, then moves it over to folder/new. At that point I will see the new mail and when I have read it my mail client moves it to folder/cur. folder/ mail-delivery rl folder/tmp/ mail-delivery rlidw folder/new/ mail-delivery rli folder/cur/ mail-delivery none I think the 'read' acl bits are technically unnecessary, but some bugs in the acl handling required them. For some reason the server doesn't allow the directory fetch to complete without 'r', even though that permission should be granted based on 'l'. Similar observation on the 'write' bit for the tmp directory, an initial write after creating a new file should be implicitly allowed, but the server has some trouble matching the initial store after the create, maybe it got confused by an attribute change. The mail delivery process is allowed to traverse into folder/, it can add and remove directory entries in folder/tmp as well as write files there. However it can only move a file to folder/new and is not allowed to modify or remove any files there. Finally it has no access at all to folder/cur. If it weren't for the small ACL handling problems, it wouldn't even be allowed to read anything that has already been delivered or write to other files that are in the process of getting delivered. Shared Git source repositories At the lowest level, git uses individual compressed blobs, which are identified by the SHA1 of their contents. These files are written once and never modified. There is an alternate storage format the 'pack' where the blobs are delta-packed a single large file. The re-packing can be done periodically by a cronjob or administrator. Developers are allowed to manage their branches 'developer/branch', but they are not allowed to directly merge into the master branch. All developers are added to the 'developers' group. project.git/objects/ developers rlidw project.git/objects/../ developers rli administrator rlid project.git/objects/packs/ developers rl administrator rlidw project.git/refs/heads/ developers rl administrator rlidw project.git/refs/heads/joe/ joe rlidw developers rl Git creates new objects in .git/objects and then moves them based on their sha1 hash into .git/objects/<sha1prefix>. This is similar to the maildir delivery process. Once an object is moved into it's final directory it can no longer be modified. Only the administrator is allowed to remove them (periodic pruning of unreferenced objects or after they have been added to the pack). Each developer has full access to a private branch directory, other developers can see, but not change the private branches. Only the administrator has the permission to merge developer branches into refs/heads/master (i.e. 'master' branch). The only problem I've found was that a developer could remove and recreate an empty object/<shaprefix> directory. This will then allow him full access to any objects that are later on added to this directory. This is easily prevented by creating zero length files (.foo) in each object directory. The developers cannot remove those files so the directories are never empty and the rmdir/mkdir trick doesn't work anymore. Oh, and there is always new development, so once in a while some change breaks things, f.i. refs may get packed at some point in which case the per-developer branch directories may break, or temporary files may get created in some different directory before they are moved. Directory ACLs used like this can be very powerful, their courseness helps because we only have to worry about what permissions to grant on a per-directory basis and there are no complicated inheritance rules, only new directories inherit the ACL of their parent we don't have to decide what ACLs to create for new files, or how they might change when files are moved from one place to another. JanReceived on 2007-02-27 12:10:34