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

[Brian Warner]

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

I'll look into what happens when you modify sys.argv in python.

cheers,
 -Brian