[tahoe-dev] Fwd: [cap-talk] Don't put capabilities in argv?

[zooko]

On Jul 16, 2008, at 21:41 PM, Rob Meijer wrote:

 > >  * add an --interactive option to 'tahoe add-alias', which causes
 > >    it to accept the cap on stdin, after asking a question
 >
 > A very good , solid and 'real' solution IMHO.

Hm -- this can also be used as a nice command-line (non-interactive)
by using echo, something like this:

echo URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde: 
4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa | tahoe put  
helloworld.txt

The "echo" bash builtin doesn't seem to appear in the process table.
Which I guess makes sense, as it isn't a process.

Cool!  I can have my old non-interactive command-line without exposing
the caps in the process tables!  It's a bit of a kludgey syntax,
having to specify the cap(s) first and then what to do with them next
(in the example above I meant "Tahoe, put helloworld.txt into the
directory denoted by the first cap on your stdin").  But kludgey
syntax is nothing new here in Unixland.  :-)


 > >  * maybe have 'tahoe get', etc, rewrite their argv to reduce the
 > >    window of vulnerability.
 > >  * fix #174 (which is about rewriting argv of 'tahoe start' to at
 > >    least mention the directory in which the node is running)

 > For these two, I learned this lessen the hard way that having a race
 > condition means having an expoitable race condition. Don't spent
 > precious development time or recources and/or add complexity to your
 > program to 'reduce the window', it is simply not woth it IMHO.

Could you tell us more about what you learned the hard way?  It sounds
plausible to me that a narrow window of vulnerability could lead to
trouble, but I would like to know to what degree it actually did lead
to trouble in practice.

Thanks!

Regards,

Zooko