Q: Access Control Options

[Stephen J. Turnbull]

Alexander Belchenko writes:

 > I don't have your experience about SVN auth solutions, and therefore I 
 > don't understand why built-in ACL support in the bzr:// protocol would 
 > hurt. I would like to understand all issues here. But as my naive 
 > expectation such thing like built-in ACL and simple users management 
 > will be so easy to use for people so everybody would love to use only 
 > the fastest bzr:// protocol because it would be so easy to set it up.

As for how ACL support can hurt, I think Maritza's point is more along
the lines of "Let's make sure it can *help*.  We must make it easy to
understand and use, and get it close to right the *first* time.
Security features are not the kind of thing where design-at-the-keyboard
and iterative application of tons of bug fixes inspire confidence in
users."

Making it "easy to understand and use" is not necessarily easy.  I
used to participate in the Coda distributed file system list.  Now,
Coda uses ACLs, and Coda ACLs have quite different semantics from
POSIX file system permissions.  This was really difficult for a lot of
Unix-experienced admins to grasp; "how can I set up permissions to do
X?" on Coda was a FAQ.  I suspect that bzr ACLs, since they will
presumably apply to whole branches and be mostly decoupled from
individual file permissions, should not be so difficult.  But it's
something that should be handled with care.

 > For example, there is still no bzr+ssh:// support on Savannah, only 
 > sftp. Why? Maybe because bzr+ssh:// is a bit harder to setup?

Basically because when bzr was introduced on Savannah, the admin did
not understand the security implications of bzr+ssh *for Savannah* (vs
*for the Bazaar repo being served*), and so did not install the smart
server.  The implications of HTTP and sftp service, on the other hand,
were well-understood, so that was acceptable.

I don't think ACLs will help in that kind of situation.  ACLs only
control damage to the bzr repo by authenticated users; it doesn't help
the host if the server itself is subverted.  That is what the Savannah
admin was worried about.

(Note, this is in no way a claim that bzr+ssh as a server is in any
way insecure; I am simply repeating the rationale as described in the
responses of the Savannah admin to repeated requests for bzr smart
server service.)