bzr serve and access control?

[Josef Wolf]

On Fri, Feb 05, 2010 at 11:14:02AM +1100, Andrew Bennetts wrote:
> First, thanks very much for taking the time to make your requirements so clear.

Thanks to you for having so much patience with me :-)

> Josef Wolf wrote:
> > On Thu, Feb 04, 2010 at 12:38:32PM +1100, Andrew Bennetts wrote:
> > 
> > > If I were to implement this, it would look like this:
> > > 
> > >   * set command="bzr acl-serve /path/to/acl-config" in your authorized_keys,
> > >   * have that config file define read/write permissions for various combinations
> > >     of paths and users,
> > >   * and write (and install system-wide) a plugin that implements 'bzr acl-serve'.
> > > 
> > > The plugin would:
> > > 
> > >   * register the 'acl-serve' command, which would:
> > >     * parse the config file determine the SSH user,
> > >     * using that info register an 'aclbzr' server in
> > >       bzrlib.transport.transport_server_registry, then
> > >     * run 'bzr serve --inet --protocol=aclbzr --directory=something'
> > 
> > So again, the directory is pretty much hardwired for a given user. Again,
> > flexibility is very limited here. For example, you can not specify multiple
> > directory hierarchies for a given user while excluding sub hierarchies.
> 
> Sorry, I was unclear.  The --directory argument there is actually unimportant, I
> should have said “ignored” rather than “something”.  The custom transport
> configured by the previous step makes it redundant; the logic that would pay
> attention to it has been overridden by the 'aclbzr' registration.

OK, I see what you mean..

> (This is
> another reason why not having an explicit sshserve command is unclear.)

But I don't get this last sentence.

> > For example, to serve my git repositories, I have configured a hierarchy
> > like this:
> > 
> >  # note: C==create, R==read, W==write, D==delete
> >  #
> >  /srv/repos/public/everybody  everybody can CRW here
> >  /srv/repos/public/<user>     user <user> can CRWD, everybody can R
> >  /srv/repos/private/<user>    user <user> can CRWD
> >  /srv/repos/some_repo         Some users can R, some can W, some can CD
> >  /srv/repos/other_repo        Some users can R, some can W, some can CD
> >  /srv/repos/one_more_repo     Some users can R, some can W, some can CD
> >  /srv/repos/repo              Some users can R, some can W, some can CD
> >  /srv/repos/repo/hierarchy    Some users can R, some can W, some can CD
> 
> Right.  This sort of thing is exactly what my proposal is intended to support.

But with a very complicated mechanism.

> [...]
> > Well, it sounds pretty complicated to me. And you have to touch bzr internals,
> > so really good knowledge about bazaar internals are needed to implement this
> > properly. And it is not backwards compatible.
> 
> It is a bit complicated, I agree, but it would only have to be written once,

Well, the gitolite-like thing would only have to be written once, too.

IMHO, Security mechanisms should never be complicated. It should be easy to
audit for security flaws. YMMV.

IMHO, the gitolite method has an more charm in addition: It follows the
old-shool unix philosophy to have small, simple, and well-separated tools
that you combine to get the functionality. Being so small, it is very easy
to audit the script for security flaws.

Bazaar seems to follow the modern linux philosophy to integrate everything
into one big blob. Although separated into plugins, there is (I suppose) no
separation regarding address space etc/pp. Any flaw in any plugin could make
the whole system vulnerable. Implementing security in such a system should
be done (if ever) only by people who are _very_ intimate with the internals.
This rules me out of the set of candidates, I guess.

> and
> then there'd be standard plugin that people could either a) configure and use,
> or b) hack and adapt for really esoteric needs.

Adopting would again need intimate knowledge about bazaar internals. And
people are dependant on core developers to get their adaptations applied
to the main line.

> In terms of lines of code, I
> think you'd find it's about half glue and about half the actual core.

For me, this does not make any difference. It's still too complicated to me.
Learning all the required bzr internals would probably take me a month or
even more.

> I'd to
> love write it myself to save someone else the trouble, but currently I have more
> urgent priorities.

Well, everybody has his priorities :-)

> This is also totally backwards compatible.  I offer as proof Launchpad: regular,
> unmodified bzr clients, with no plugins enabled, will happily interact with
> Launchpad's code hosting,

Well, I was talking not only about compatibility with old clients, but also
about compatibility with old servers.

> which not only implements access controls like the
> above, but also enforces rules like “second directory element must be a project
> name in Launchpad” and mapping the public directory names to internal names
> based on database ID so that renaming branches doesn't affect the referential
> integrity of Launchpad's database.

Well, I have to give up here. I don't have enough bzr knowledge to follow you
here.

> > Look, I have implemented the thing described above for git in less than 50
> > (trivial) lines of perl. Without knowing about git internals and without
> > touching git at all. Just a matter of getting directory and access method
> > from the command line and act according the config file. Not a big deal.
> > Took me less than two hours and I can be 100% sure I have not broken anything
> > in git. And since the code is trivial, it is easy to check for correctness.
> 
> There's a fundamental difference in the way that bzr operates that prevents
> this, namely the way we deal with branches and repositories over an arbitrary
> number of directory levels, whereas git you can point at single filesystem
> location and know that all the heads and revision data can be found inside it.
> For this task, it places bzr at a disadvantage, but one that can be readily
> fixed by writing a server-side plugin to configure bzr accordingly.

The only problem here is the word "readily"...

> (On the other hand, bzr's layout also means that you can apply regular
> filesystem ACLs to individual branches, so it's not all disadvantage.)

For that you need to create real user accounts.

> > Implementing your proposal would take me at least a month and would
> > have a big risk to break something. And it would still not give me the
> > flexibility that I already have with the damn 50 lines of trivial perl for
> > git.
> 
> Fair enough, I appreciate it's not worth the effort for you (although I disagree
> about the degree of flexibility you'd get).

Well, it's not only about the effort. It is also a sort of chicken+egg
problem: To get the required knowledge, I need to work with bzr for a
while. But to do serious work with bzr, I need a proper setup...