bzr serve and access control?

[Stephen J. Turnbull]

Ben Finney writes:

 > Can you please explain what you mean by this statement:
 > 
 > > This way you end up with having lots of user accounts, which you
 > > might not want to have, since it is a server.

He doesn't want people to have access to the host itself.  He wants
them to have access to particular services provided by the host, and
*only* those services.

So instead of giving Alfred, Beth, and Carl individual system
accounts, which requires the security system to keep track of what
Alfred, Beth, and Carl are allowed to do individually, he wants to
have a single account whose only privilege is to access and mutate bzr
repositories.

If Alfred, Beth, and Carl were exactly the same in privilege, this
could be accomplished with a Unix group.  However, it is often the
case that you want to restrict Carl, say, to read-only while Alfred
and Beth can read and write.  And Josef has said exactly that.

So Josef is, I think, looking for layered security.  You come in
through (say) https, which offers the host no real security -- it
doesn't know who you are.  Now you authenticate to the VCS subsystem
(which may include components other than the VCS itself, and since bzr
has no such function, will have to in a system using bzr), and it now
offers you appropriate privileges.  However, you do not have a system
account, so you can't do anything yourself except talk to bzr.

Now the system only has to check on the bzr account.  It doesn't care
what bzr does with its resources.  It doesn't need to know who you
are.  It has delegated those resources to bzr, including security.
But if bzr tries to touch any non-public resource (except its own),
the alarm rings and the cops come running.

The extreme example of this kind of architecture under Unix, of
course, is a sendmail virtusertable, which has no permanent resources
on the server except the table itself.

In other words, what he really wants is Plan 9.  ;-)

But there are other ways to accomplish this.  He could have a
dedicated host that does nothing but run bzr.  Then he can emulate the
above architecture by saying there's root, and there's everybody else,
who must be bzr users.  Virtual hosts, chroot, chsh /bin/false,
etc. all provide varying degrees of isolation.