[cap-talk] Don't put capabilities in argv?
kpreid at mac.com
Sat Jul 12 20:51:25 CDT 2008
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/>
More information about the cap-talk