ACLTransport and Other ACL Thoughts

[Jeff Abbott]

Hello, John!  Thanks for the input.

John Arbash Meinel wrote:

> At the moment, people who have asked for more ACL support seem to
> want it without using the filesystem. I suppose because you can
> already do it via the filesystem.

Right, which is another reason why I'm leaning that way for bzr+ssh:// 
access.

> I'm still trying to figure out if you are trying to do working-tree
> ACLs or Branch/Repository ACLs. I realize in SVN they are the same
> thing, so it does take a bit more thought to separate them out again.

I'm sorry, I should've been more clear with Bazaar terminology; I'm 
still new to bzr so I may slip up like this occasionally.  This is for 
the branch/repository side of things, not the working-tree.  It's 
designed to manage access to the centralized, canonical source, what 
would be considered the server-side in the Subversion world.

The workflow that I'm modeling it for is #5, "Decentralized with shared 
mainline," from http://bazaar-vcs.org/Workflows, though it would also 
apply well to #3 and #4.

> 1) One of the fundamental benefits to a distributed source control 
> system is that anyone can create a branch without getting
> authorization from a 3rd party, hack on it and commit locally, and
> still get full support from the SCM.

Absolutely, and this would not attempt to prevent people from sharing 
with one another, only with getting their changes back into the 
mainline.  It would also stop people from getting at repositories and/or 
branches they weren't allowed to access, for one reason or another.

> 2) Often people with large source repositories want to hide parts of
> it. Or restrict who can modify it (even if they can read it).

I'm less concerned with hiding a given repository and/or branch 
completely, though this certainly could be a useful feature for others.

> At the moment, you can already do that with separate branches and 
> filesystem/apache ACLs. At least to a point. People who have read
> access can create their own branch and commit locally, but don't have
> to be allowed to push their changes to the official location.

This is precisely what I'm after, and while it's clear on how to do it 
with the file system -- chmod and chown are your friends -- it's not 
clear how to best do it with Apache.  If I use <Location> directives 
with Require options, bzr chokes (I don't remember how, exactly, at the 
moment, but if you think it'd be worthwhile I'd be happy to re-test and 
file a bug with the traceback).  It's also not as elegant a solution as 
I'd like, and it prevents external tools -- like Loggerhead -- from 
being able to leverage the same authorization data in Bazaar, since 
there is none.  We use ViewVC and Subversion here, and it's wonderful 
that we only have to specify user and group permissions in one place.

> It would also be possible to have a configurable system, so that at 
> (say) commit time, it would say "you aren't supposed to modify files
> in doc/*". And either ignore them for commit, or abort the commit if
> they are included. (People could always do "bzr commit
> stuff/I/can/touch".)
> 
> Now, this would be a client-side restriction, and I would fully
> expect that someone who knew what was going on would be able to get
> around it.

In retrospect this would probably prove to be more trouble than it's 
worth.  I think that repository-wide ACLs that apply to specific 
branches (or all branches) would be good enough.

> So the second stage might be wanting to prevent that person from
> publishing changes to those files to the official location. *That* is
> rather difficult.
> 
> If you used a merge bot like PQM, you could give it a rule that says
> "when merging a commit from Foo make sure only files in these areas
> are modified, else reject the merge." However, if you are just
> exposing the branches via bzr+ssh I don't really see how to do it
> easily. Basically, when a push comes in, you need to inspect each
> revision, and decide if that user is actually allowed to change 
> things in that way. Even worse, say I make a change and commit
> locally, and then I hand it to you. *You* should be able to merge
> that into the mainline, even though it will be marked as committed by
> me. Though if I merge your change, I... probably shouldn't.
> 
> Again, a fairly logical way to do it is to split things up. If things
>  are going to get a different ACL, they get a different branch. And
> then you set up ACLs by the branch.

Which, considering the difficulties inherent with saying, "You can write 
to this directory in the branch but not these," only further reinforces 
my belief that I unnecessarily went off the granularity deep-end in my 
initial message.  :-)

Thanks,
Jeff