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.

Jan