[cap-talk] Definition of "authority"? Got it right?

Jed Donnelley capability at webstart.com
Tue Jan 22 01:21:04 EST 2008


At 08:12 PM 1/20/2008, Mark Miller wrote:
>On Jan 18, 2008 7:24 PM, Jed Donnelley <jed at nersc.gov> wrote:
>...
> > Sorry for the struggle.  I just don't seem to be getting
> > it.  MarkM suggests that Chapter 8 in his thesis focuses
> > on this topic.
>
>Thanks for struggling. Chapter 8 is indeed the key. I myself am
>struggling to figure out what more I can say than what I've said in
>the thesis -- sorry...

OK, I think I have it.  Following David Wagner I focused on
that paragraph 5 in section 8.1 and specifically this sentence:

"Bob's authority derives from the structure of permissions
(Alice's write permission, Bob's permission to talk to
Alice), and from the behavior of subjects and objects
on permitted causal pathways (Alice's proxying behavior)."

Perhaps finally after all this reading, but this does
finally seem to fit now with what AlanK was saying,
though let me pick up on some details below.

Let me restate this current 'understanding' in some
other words to see if I'm really getting it:


A subject's "permissions" are what it can get the
Trusted Control Block to do on it's behalf
(e.g. Bob's communication, Alice's file writing).

A subject's "authority" is what it can get
other programs to do on its behalf by exercising
its permissions.

Since this is such a radically different way
of stating things, I guess I should wait for
a response from MarkM or others.

<stop and respond if I still have it wrong>

I think one thing that has been confusing me
is that, for example, in the above quote from
section 8.1, it discusses Bob's "permission"
to talk to Alice, but Alice's "permission" to
write to the file - a higher level concept
in my thinking.  I tend to always think of
file access being provided by the "file
server" (NLTSS habit I'm afraid).  In such
a case MarkM (I believe) would say that Alice
has permission to talk to the file server
and only the "authority" to write to
the file (check me again - I believe now
that is right), as the action of writing
to the file requires the active participation
of the File Server (rather than just the TCB).

Right so far?

If not: <stop and respond>

What bothers me about this definition
set is that, at least for object
capability systems, it seems to
somewhat trivialize the notion of
a "permission".  Permissions are
always the same.  They only provide
communication.  The real semantics
of what a capability allows a
subject to do (e.g. a capability
to "write" to a file, a capability
to 'stop' a process, a capability
to 'read' from a keyboard, etc.,
etc.) by this set of definitions
isn't the "permission" of the
capability but rather the "authority".

Doesn't this seem to trivialize
the "permission" notion where the
permissions are always the same?
Perhaps it is more useful in systems
with richer TCBs?

When I think of "access rights" (e.g.
"write" access to a file), in capability
systems, they exist in the "data" of
the capability (something delivered
to the server/object when an invocation
happens).  This is what I've tended
to think of as a "permission".  Of
course that notion is at odds with
MarkM's definition that only gets to
the TCB level.  The only "permission"
that a subject would have is the ability
to deliver any such "access bits" (e.g.
capability data) to the server (object).

I suppose then that something like "access
right"s in a capability might be referred
to as "authorities" because they are provided
by the action of the object (server
process)?

Oh well, they're just words.  I hope I've
finally gotten it right.  Of course MarkM
goes on to define a whole set of permission
and authority notions:
Emacs!


that still puzzle me some, but I think I won't go
there in this message.  Maybe for a face to face
discussion some time.

Thanks to everybody for helping me through this (and
in advance for correcting me if I still have it wrong).
Sorry if it was wasted reading for others.

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20080121/1a2a060d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 79631e7.jpg
Type: application/octet-stream
Size: 199793 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20080121/1a2a060d/attachment-0001.obj 


More information about the cap-talk mailing list