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

Rob Meijer capibara at xs4all.nl
Thu Jul 17 03:41:28 UTC 2008


Hi, I havn't posted on this list before, I joined the list to not lose track
of the tahoe-dev part of this discussion, and from an interest in Tahoe as
it is in its concepts (aparently not its implementation) very much simular
to my MinorFs project.

(MinorFs is absolutely dwarved by Tahoe as in codebase, I don't have the
number of lines that tahoe does as source files, what seems absolutely
enormous)

>From this, let me give my input.

On Thu, July 17, 2008 00:51, Brian Warner wrote:
> On Sat, 12 Jul 2008 21:29:30 -0700
> Aleksandr Milewski <zandr at allmydata.com> wrote:
>
>> A pragmatic $0.02.
>>
>> We should allow a mechanism to keep caps off the commandline. We should
>> also allow them, because they're convenient and the process table leak
>> is
>> not always a concern.
>>
>> If we do allow caps on the commandline, we should rewrite argv to reduce
>> the window where the leak occurs.
>
> I agree. Being able to do 'tahoe get CAP' is awfully handy, and none of
> the
> unix boxes that I use are shared with people I don't trust. The debate
> reminds me a little bit of the argument against putting caps in URLs:
> various
> browser bugs and misfeatures make it difficult to keep URLs secret, so
> let's
> come up with weird workarounds to hide or mangle the URLs.
>
> Here's what I think we should do:
>
>  * 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.

> (or maybe just use
> 'tahoe
>    add-alias ALIASNAME -', as a relatively well-known convention for "get
>    this thing from stdin"). Users who share a unix box with adversaries
> can
>    use it.

Not as good as the first solution, but if you can't have 'least' authority
having 'less' authority is not all that bad.


>  * 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.


Rob J Meijer




More information about the tahoe-dev mailing list