ACLTransport and Other ACL Thoughts

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff Abbott wrote:
| Alexander Belchenko wrote:
|
|> I comment some of your thoughts. But I could be wrong in some aspects.
|
| Thanks for the feedback, Alexander!
|
|> I'm not expert in bzr+http, but may be (just may be as an idea) it's
|> better to implement as subclass (or maybe mixin) of RemoteTransport?
|> So it will be deeper pluggable into all bzr+*:// combinations?
|
| I suppose that's a possibility.  Ideally this support would be
| integrated in such a way that ACLs would be available to any access
| method.  I'd want it to be restrictive of bzr+http:// and bzr+https://,
| as well as have an API for other tools (like Loggerhead) to use.  So
| maybe a decorator isn't the best way to go.  Perhaps in
| RemoteHTTPTransport itself we could override get, get_bytes, and the
| various put and append methods to check ACLs first?
|
| I'm also on the fence about whether or not I'd want this to be available
| to bzr+ssh:// or if the file system would be the right place to secure
| that transport.  I'm leaning towards leveraging the file system at the
| moment, for what it's worth.

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.

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.

There are a few conflicting goals here.

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.

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).

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.

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.

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.

If you use a shared repository, people can still get stuff into the repo that
modifies X or Y. *But* it won't be exposed to people who "bzr branch mainline".


|
|> One problem here is on the server you don't touch actually working tree
|> for push/pull/branch/commit operations. So it seems like provide fine
|> grained access within working tree of one branch will be very hard.
|> Because now bzr works with branch as a single whole.
|
| That's a good point, and is something I hadn't really realized.  I guess
| providing repository-level access would be the only way at the moment.
|
|>> I'm not sure if we'd need, or even want, that level of granularity,
|>> but it seems like it'd be better to implement that now rather than do
|>> it more coarsely and have to re-think things again in the future when
|>> someone finds a good case for it being more precise.  I'm also not
|>> convinced that .bzr/branch/branch.conf is the right place for this
|>> information; perhaps .bzr/branch/access.conf would work better?
|>
|> As I said above it's better to place on repository level and control
|> access to particular branches.
|
| That's also a very good point, since every branch has a repository
| somewhere (even if it's all in one).  So, .bzr/repository/access.conf
| would probably be the right way to go.  It would require people learn
| about the distinction between repositories and branches in Bazaar, but
| it's not that complicated and, frankly, if you're running a Bazaar
| server used by multiple people then you should probably understand such
| things anyway.
|
| Thanks,
| Jeff
|

Well, it is fairly fundamental in Bazaar. For a variety of reasons. (One of the
oddities in SVN is that you can commit a tree, but when you check it out at the
same revision, it will be different because someone changed things in files that
you didn't modify.) We have been trying to introduce NestedTrees to bring back a
little bit of flexibility. It starts to create boundaries where all the data in
*this* subset will stay consistent, but doesn't have to stay consistent with
*that*, while still allowing you to get everything with a single "checkout".

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHx0SoJdeBCYSNAAMRAtdKAJ0VmoKJnnVgAnM80nIOMt/ViTkHtwCgkiyv
h5Tu7yIrZOKzHWtuDDR0HtE=
=JOzf
-----END PGP SIGNATURE-----