[cap-talk] Don't put capabilities in argv?

[Kevin Reid]

On Jul 12, 2008, at 21:10, Dean Tribble wrote:
> You could also follow the pattern in the "what if files were
> objects"examples and use "command < cap" to get the capabilities over
> a stream.


Hey, this generalizes. Given a shell at least as capable as bash, you  
can pipe in multiple non-file sources. e.g.

foo-cap-receiver <(bar-cap-generator) <(baz-cap-generator)

and this eliminates needing to clean up temporary files. You just need  
some command which takes some non-authority-bearing designation of the  
actual capability (or already knows it, or determines it in some  
application-specific way), and writes the capability to stdout.

Basically, all these read-from-specified-file schemes are introducing  
a sort of c-list. The capabilities are referenced by filenames (~=  
clist indexes), but not actually constituted by them. In the case of  
<(...), the filenames are even a (sloppy) local namespace: /dev/fd/*  
(or whatever it is on your OS).


A broken idea I just had:

Generate a symmetric encryption key. Write it to a well-known location  
in the user's home directory. Encrypt all capabilities which might be  
passed over argv.

This would work transparently -- until you try to delegate to anything  
not in this account. Whoops.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>