bzr serve and access control?

[Andrew Bennetts]

Josef Wolf wrote:
[...]
> How about that:
> 
> Currently, --directory=/ is hard coded into the client, and it fails if
> the server refuses access.
> 
> What if, instead of failing, it would retry with --directory=/srv and so on.
> Finally, with --directory=/srv/repo (in the above example) it would succeed
> and could continue as if nothing happened.
> 
> That would be fully compatible to the current behavior, since the very first
> try would succeed on servers without restrictions. But it would also allow
> the server to refuse access to specific areas.
> 
> Opinions?

I think this would be very slow (SSH connection setup over the internet is
regularly in the order of multiple seconds, so adding possibly as many as 5
extra connection attempts will be a huge delay).

I think it's better to think of that command the client asks for as just an
arbitrary (but fixed) string meaning “give this user a bzr session, please”.
By default, bzr installs will create a bzr session that gives you the same
filesystem access as the system user has.  If you want to implement a
different policy then that's what the command="..." option in
authorized_keys is for.  See my other post today about how to write a plugin to
handle this use case.

I actually wish I'd created a dedicated 'sshserve' command or similar with
no --directory argument, instead of making the client invoke 'bzr serve
--allow-writes --inet --directory=/'.  The command line that bzr's SSH
client executes is a sort of attractive nuisance: it looks to the
uninitiated like a value that the client/user is supposed to manipulate, but
attempts to do so are (in my opinion) misguided.  At times even I've been
tempted into thinking that, but I've been wrong :)

-Andrew.