Re: [Monotone-devel] list branches on server?

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> On Sat, 2009-08-22 at 19:13 +0200, Thomas Keller wrote:
>> Stephen Leake schrieb:
>> > Timothy Brownawell <address@hidden> writes:
>> > 
>> >> On Sat, 2009-08-22 at 09:44 -0400, Stephen Leake wrote:
>> >>> Is there a way to list the branches in a database on a server, without
>> >>> downloading the whole database?
>> >> Not yet, that happens after we move to ssl transport and enable
>> >> 'automate stdio' over the network.
>> > 
>> > That makes sense.
>> > 
>> > How is that going? I have some time to spend; can I help in some way?
>> 
>> One of the currently unresolved issues I can think of here is the
>> security model which has to be applied. For now the `automate` interface
>> has no security model at all, thus you can do everything on the database
>> as soon as you get access to a running instance.
>> 
>> Maybe we should get an idea of how to manage security here first?
>
> Use people's monotone keys as (self-signed) client certificates
> (assuming it doesn't make sense for there not to be a way to retrieve
> the key info from the ssl layer), and add a lua hook
> "get_automate_command_permitted(command_name, key_info)" that's checked
> when anyone tries to an automate command from the network. So everything
> would be controlled by lua hooks, based on the key the client uses.

And the default hook returns false, so all permissions have to be
explicitly added?

And that hook has to run on the server, not the client.

We could leave it up to the hook to get the key_info, assuming there
are Lua functions to do that. It could alternately just use the ssl
login name, or something else.

But I guess the key_info is the best form of user identification?

On the other hand, ssl already has its own access control. Do we
really need another layer?

I guess we do; if there are several monotone databases on a machine,
they might want different permissions, while ssl just grants access to
the machine.

Where do we write down these design decisions?

-- 
-- Stephe