monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] re


From: Stephen Leake
Subject: Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band
Date: Sun, 29 Nov 2009 10:09:17 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt)

Thomas Keller <address@hidden> writes:


>> $ { echo o6:rcfile5:x.luael3:lua3:fooe;
>>     echo o6:rcfile5:y.luael3:lua3:fooe; } |
>>   mtn -d :memory: --rcfile i.lua au stdio >/dev/null
>> i
>> i
>> 
>> 
>> 
>> ...no, looks like --rcfile given on individual commands doesn't take. I
>> guess because we call app.lua.load_rcfiles() in monotone.cc but not in
>> the automate stdio loop, maybe this should be changed? Or maybe it
>> shouldn't, since with remote_stdio this could be a problem if someone
>> untrusted can write somewhere on the filesystem and call even
>> interface_version.
>
> How so? A file given to --rcfile is a remote file, so a foreign user
> might only load additional, previously existing lua files, right? Of
> course he could upload via ftp or something else a malicious lua file
> and load that into remote_stdio - so maybe this option should be
> disabled for that use case in general?

The first --rcfile (on the mtn command line; i.lua above, if it was
remote_stdio) is on the local disk, right? It's the others (x.lua,
y.lua) that should be on the remote disk.

So the current behavior is safe,  but it should give an error message
about ignoring --rcfile on the stdio commands.

I don't think we need to load rcfile on each local stdio command. I
think a stdio session should cache as much as possible, not emulate
the complete mtn startup for each command.

On the other hand, perhaps we should have two modes for stdio; "full
caching" vs "no caching", depending on what the user is doing. The
later mode would respect --rcfile, for example, while the former would
ignore --rcfile and assume the workspace doesn't change except via
commands processed by the stdio session (so it could cache the
workspace revision object between commands).

On the gripping hand, do we need to make remote mtn access safer than
general access to the remote machine? I guess a mtn server process
will typically have more priviledges than a normal user login, so the
answer is "yes".

There is a use case for a set of lua functions that are enhancements
available to the server monotone; they would be in the rcfile
read when the server starts, and are therefore safe.

Is there a use case for loading different server-side enhancements
after startup, say for different users? or remote_stdio vs normal
access? I think the server only has one Lua namespace, not one per
user, so I don't this is possible. There's also no way to "forget" the
definitions in the last loaded file.

Actually, that's another reason to ignore --rcfile in remote_stdio; it
changes the server behavior for other users as well.

-- 
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]