bzr serve and access control?

[Josef Wolf]

On Tue, Feb 02, 2010 at 03:41:30PM -0600, John Arbash Meinel wrote:
> > To illustrate: when I invoke
> > 
> >   bzr clone bzr+ssh://bzr-user@host.do.main/foo/bar
> > 
> > then
> > 
> >   bzr serve --inet --directory=/ --allow-writes
> > 
> > is invoked on the remote side. IMHO, there are two things wrong here:
> > 
> > First problem is that the --allow-writes option is passed. But isn't "clone"
> > a read-only operation? So why is the --allow-writes option passed here?
> > 
> > Second problem is that the /foo/bar part is dropped. Why not invoke 
> > 
> >   bzr serve --inet --directory=/foo/bar
> 
> It is more obvious if you say
> 
> bzr init-repo /srv/repo
> mkdir /srv/repo/a_project
> bzr init /srv/repo/a_project/branch
> 
> bzr branch bzr+ssh://host/srv/repo/a_project/branch

Sorry, but this is not obvious to me at all. What would be wrong with
--directory=/srv/repo/a_project/branch in this case? Why does the client want
to be able to access not only the desired repository, but _all_ data on my
machine? After all, this is (semantically) what '--directory=/' means (which
is hard-wired in the client, BTW)

> The --directory argument to bzr serve gives the *root* of the served
> filesystem.

Wouldn't it make more sense to be the root of the served _repository_?
Or the root of the served _branch_? Why do they care about my _filesystems_?

> We ensure that you cannot access any filesystem path outside
> of this space.

Well, I'm pretty sure there is _really_ no way to access _anything_ outside
of '/'. What are you trying to protect outside of '/'? Or can bzr protect
against escape from chroot? I don't buy that one.

Remember: the '/' is hard-wired into the client. So what are you trying to
protect me from?

> So that people can run 'bzr serve --directory=/srv/repo'

So why doesn't the client run that? Why does it run "bzr serve --directory=/"
instead of that?

Anyway, I guess you agree that the semantics should be "repository" instead of
"filesystem"? /srv/repo is the location of the _repository_, isn't it?

> if they want to set up public access to a repository, and not allow
> external users access to anything but that repo.
> 
> If for the above 'bzr branch' we did:
> 
> bzr serve --inet --directory=/srv/repo/a_project/branch
> 
> Then the server would refuse access to the 'repository'. The client does
> not know *where* the repository is until we've connected. (As it could
> have been in /srv/repo, or /srv/repo/a_project or
> /srv/repo/a_project/branch.)

How comes that the client doesn't know where the repos is located although
I have passed this information on the command line?

If you say "bzr branch bzr+ssh://host/srv/repo/a_project/branch" (as in
your example above), it looks pretty much as you are trying to access
/svn/repo/a_project/branch on "host". How comes that bzr client is not able
to know that? How can it retrieve the data when it doesn't know where to
get it from?

You are trying to branch from "/srv/repo/a_project/branch" on host "host".
So why not tell --directory=/srv/repo/a_project/branch?
Why does the client insist to tell --directory=/ and pretend it wants
to access all available data on my host?

> In the end, we can do all the access control that one would need, you
> just have to do it from within bzr, rather than trying to it from shell
> above bzr.

The only problem is: bzr doesn't seem to do any access control at all,
AFAICS. It relies on ssh/filesystem/webserver/whatever for access control.
That's the very reason why we could not find a solution in this thread (yet).

> Somebody else pointed out:
>   http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer
> 
> Which IIRC does exactly that. It provides an ACL based transport that
> restricts access based on an htpasswd style password file.

Looks interesting, and I'll check that out. But I don't think this to be
a proper solution for the problems discussed in this thread. Throwing even
more complicated layers onto the problem is not the way you want to solve
security issues.

> Now I believe clue-bzrserver serves over HTTP access, but it should be
> performance equivalent to bzr+ssh.

Performance is not really a concern as long as security isn't done right.
BTW: Does ClueBzrServer do https?