ACLTransport and Other ACL Thoughts
fdiv_bug at sniping.org
Fri Feb 29 03:16:48 GMT 2008
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://
> 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
> 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. :-)
More information about the bazaar