[tahoe-lafs-trac-stream] [Tahoe-LAFS] #840: Allow all CLI commands to take arguments from stdin or a file, to avoid caps being visible to other local users

[Tahoe-LAFS]

#840: Allow all CLI commands to take arguments from stdin or a file, to avoid
caps being visible to other local users
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:
  davidsarah             |     Status:  new
         Type:           |  Milestone:  undecided
  enhancement            |    Version:  1.5.0
     Priority:  major    |   Keywords:  security confidentiality integrity
    Component:  code-    |  usability
  frontend-cli           |
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Old description:

> From code:docs/known_issues.txt :
>
> >=== command-line arguments are leaked to other local users ===
>
> >Remember that command-line arguments are visible to other users (through
> the {{{ps}}} command, or the windows Process Explorer tool), so if you
> are using a Tahoe-LAFS node on a shared host, other users on that host
> will be able to see (and copy) any caps that you pass as command-line
> arguments.  This includes directory caps that you set up with the
> "{{{tahoe add-alias}}}" command.  Use "{{{tahoe create-alias}}}" for that
> purpose instead.
>
> >==== how to manage it ====
>
> >Bypass {{{add-alias}}} and edit the {{{NODEDIR/private/aliases}}} file
> directly, [...] By entering the dircap through the editor, the command-
> line arguments are bypassed, and other users will not be able to see
> them. [...]
>
> >Starting in Tahoe-LAFS v1.3.0, there is a "{{{tahoe create-alias}}}"
> command that does this for you.
>
> This workaround using aliases is ugly -- adding a persistent alias for an
> argument that might only be used once has poor usability, leaving around
> aliases may constitute a privacy issue, and firing up an editor is quite
> a heavyweight solution.
>
> Proposed feature: if a CLI command sees an argument of the form
> "{{{@filename}}}", then it substitutes the contents of that file into the
> command arguments in place of "{{{@filename}}}" (taking newlines as
> argument separators). "{{{@}}}" on its own does the same thing for
> standard input. If the file cannot be read then the command fails with no
> effect.
>
> (In other words, {{{@filename}}} works similarly to the Unix shell syntax
> {{{`cat filename`}}}, except that the latter wouldn't solve the problem
> because it passes the file contents via the command line.)
>
> The syntax {{{@filename}}} is chosen because it seems to be a semi-
> convention, at least in developer tools (e.g. MSVC++, javac, javadoc use
> it), and because {{{@}}} does not need to be quoted on either Unix or
> Windows.

New description:

 From code:docs/known_issues.txt :

 >=== command-line arguments are leaked to other local users ===

 >Remember that command-line arguments are visible to other users (through
 the {{{ps}}} command, or the windows Process Explorer tool), so if you are
 using a Tahoe-LAFS node on a shared host, other users on that host will be
 able to see (and copy) any caps that you pass as command-line arguments.
 This includes directory caps that you set up with the "{{{tahoe add-
 alias}}}" command.  Use "{{{tahoe create-alias}}}" for that purpose
 instead.

 >==== how to manage it ====

 >Bypass {{{add-alias}}} and edit the {{{NODEDIR/private/aliases}}} file
 directly, [...] By entering the dircap through the editor, the command-
 line arguments are bypassed, and other users will not be able to see them.
 [...]

 >Starting in Tahoe-LAFS v1.3.0, there is a "{{{tahoe create-alias}}}"
 command that does this for you.

 This workaround using aliases is ugly -- adding a persistent alias for an
 argument that might only be used once has poor usability, leaving around
 aliases may constitute a privacy issue, and firing up an editor is quite a
 heavyweight solution.

 Proposed feature: if a CLI command sees an argument of the form
 "{{{@filename}}}", then it substitutes the contents of that file into the
 command arguments in place of "{{{@filename}}}" (taking newlines as
 argument separators). "{{{@}}}" on its own does the same thing for
 standard input. If the file cannot be read then the command fails with no
 effect.

 (In other words, {{{@filename}}} works similarly to the Unix shell syntax
 {{{`cat filename`}}}, except that the latter wouldn't solve the problem
 because it passes the file contents via the command line.)

 The syntax {{{@filename}}} is chosen because it seems to be a semi-
 convention, at least in developer tools (e.g. MSVC++, javac, javadoc use
 it), and because {{{@}}} does not need to be quoted on either Unix or
 Windows.

--

Comment (by daira):

 "@" has unfortunately been used up for a different purpose by
 [3798d9946e1f62cc7b9b83c641f6f0eb21864a2c/trunk].

 I suggest "!" instead, because it is not a shell metacharacter for either
 Windows `cmd.exe` or most Unix shells (outside `[]`).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/840#comment:6>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage