[cap-talk] ... enforcement - hope? Capabilities as clumsy, not

[Ian Grigg]

Ben Laurie wrote:
> David Wagner wrote:

>> Sure.  The prototype for main() says that the caller must pass in a list
>> of strings.  If the caller wants to pass a file to the program, the 
>> caller
>> does so by passing a string that holds the file's name.  That violates
>> capability discipline.  There is no way to arrange that argv[1] holds
>> a capability to the file, instead of a filename represented as a string.
> 
> 
> Why not? Use a namespace that encapsulates the swiss number (a term I 
> haven't seen for a while, is it out of fashion? Where did it come from 
> anyway?) of the capability. Done, surely?

Isn't one of the rules that a capability reference
cannot be forged?  Like an object reference?

I think I appreciate DAW's point here.  It doesn't
matter that one can create a capability internally,
what matters is whether you can pass a capability
securely (unforgeably, etc) from one program to
another.

Isn't this what is meant by passing a capability
from one domain to another?

I gather in Unix there is a way to pass file
descriptors from process to process.  I've never
used it, but if one could model all resources as
files (an original design goal, but long since
forgotten) then, does that get us closer?  Hmm,
no, there is dup(2), and fds are forgeable anyway
:-/

iang