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

[zooko]

(Re-adding the cap-talk mailing list because they might be interested  
in the general question of what sorts of command-line tools could be  
invented to manage caps.)

On Jul 21, 2008, at 21:57 PM, Aleksandr Milewski wrote:

> I do find it much worse, yes. I'm all for allowing a mechanism to keep
> caps out of the process table, but I don't want to make the software
> harder to use in cases where that protection is irrelevant.

(and in an earlier message, Zandr wrote:)

> am genetically predisposed against systems trying to
> protect me against myself.

Quite right.  Many security engineers seem to think that they know  
better than their users do how the users ought to value security vs.  
other values such as usability and performance.  I have little  
sympathy for that attitude.

I understand that you are satisfied with trusting all code and users  
that get to run on your systems, and I understand that Brian is  
satisfied with using the aliases file to manage caps.  I'm glad of that!

However I remain interested in whether there could be a tool which  
was useful to people who were not satisfied by either of these  
approaches -- a tool which would allow people to use caps directly on  
the command-line while also allowing them to have untrusted users or  
run untrusted code on the operating system.

I can see one possibility: shell functions and builtins don't appear  
in the ps table, so for example if tahoe accepted caps on stdin, then  
a bash function like this would allow convenient command-line use  
while keeping the cap out of the process table entirely:

function tahoe_put {
	echo ${1} | tahoe put ${0}
}

This could then be invoked on the command line as

tahoe_put helloworld.txt URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde: 
4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa

Obviously this isn't the perfect solution for everyone's use either.   
For starters, you have to be using bash (or a sufficiently similar  
shell), and next you have to define this function, such as by adding  
it to your .bashrc, before you can use it.

But it is a potentially interesting alternative.

> FWIW, I disagree with the argument against rewriting argv at all, but
> I'm not well prepared to argue that point. :)

Yes, that's a subtle one.  I could see it either way and I would be  
interested in your argument.

Regards,

Zooko