On Sat, 2009-08-22 at 14:01 -0400, Stephen Leake wrote: > Timothy Brownawell <tbrow...@prjek.net> writes: > > > On Sat, 2009-08-22 at 19:13 +0200, Thomas Keller wrote: > >> 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.
Yes. > 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 didn't think ssl had login names, just certificates (keys). Are you thinking ssh here, or are there more features available than I thought? > 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. We do need something more detailed than "connected" vs "not connected", for example like what get_{read,write}_permitted() currently allow. > Where do we write down these design decisions? I guess it would need a wiki (but how can it be a wiki without an edit button?) page. I don't see anything there now, besides a brief mention on the FutureCryptography page. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel