<html>
<body>
At 08:12 PM 1/20/2008, Mark Miller wrote:<br>
<blockquote type=cite class=cite cite="">On Jan 18, 2008 7:24 PM, Jed
Donnelley &lt;jed@nersc.gov&gt; wrote:<br>
...<br>
&gt; Sorry for the struggle.&nbsp; I just don't seem to be getting<br>
&gt; it.&nbsp; MarkM suggests that Chapter 8 in his thesis focuses<br>
&gt; on this topic.<br><br>
Thanks for struggling. Chapter 8 is indeed the key. I myself am<br>
struggling to figure out what more I can say than what I've said in<br>
the thesis -- sorry...</blockquote><br>
OK, I think I have it.&nbsp; Following David Wagner I focused on<br>
that paragraph 5 in section 8.1 and specifically this sentence:<br><br>
&quot;Bob's authority derives from the structure of permissions<br>
(Alice's write permission, Bob's permission to talk to<br>
Alice), and from the behavior of subjects and objects<br>
on permitted causal pathways (Alice's proxying behavior).&quot;<br><br>
Perhaps finally after all this reading, but this does<br>
finally seem to fit now with what AlanK was saying,<br>
though let me pick up on some details below.<br><br>
Let me restate this current 'understanding' in some<br>
other words to see if I'm really getting it:<br><br>
<br>
A subject's &quot;permissions&quot; are what it can get the<br>
Trusted Control Block to do on it's behalf<br>
(e.g. Bob's communication, Alice's file writing).<br><br>
A subject's &quot;authority&quot; is what it can get<br>
other programs to do on its behalf by exercising<br>
its permissions.<br><br>
Since this is such a radically different way<br>
of stating things, I guess I should wait for<br>
a response from MarkM or others.<br><br>
&lt;stop and respond if I still have it wrong&gt;<br><br>
I think one thing that has been confusing me<br>
is that, for example, in the above quote from<br>
section 8.1, it discusses Bob's &quot;permission&quot;<br>
to talk to Alice, but Alice's &quot;permission&quot; to<br>
write to the file - a higher level concept<br>
in my thinking.&nbsp; I tend to always think of<br>
file access being provided by the &quot;file<br>
server&quot; (NLTSS habit I'm afraid).&nbsp; In such<br>
a case MarkM (I believe) would say that Alice<br>
has permission to talk to the file server<br>
and only the &quot;authority&quot; to write to<br>
the file (check me again - I believe now<br>
that is right), as the action of writing<br>
to the file requires the active participation<br>
of the File Server (rather than just the TCB).<br><br>
Right so far?<br><br>
If not: &lt;stop and respond&gt;<br><br>
What bothers me about this definition<br>
set is that, at least for object<br>
capability systems, it seems to<br>
somewhat trivialize the notion of<br>
a &quot;permission&quot;.&nbsp; Permissions are<br>
always the same.&nbsp; They only provide<br>
communication.&nbsp; The real semantics<br>
of what a capability allows a<br>
subject to do (e.g. a capability<br>
to &quot;write&quot; to a file, a capability<br>
to 'stop' a process, a capability<br>
to 'read' from a keyboard, etc.,<br>
etc.) by this set of definitions<br>
isn't the &quot;permission&quot; of the<br>
capability but rather the &quot;authority&quot;.<br><br>
Doesn't this seem to trivialize<br>
the &quot;permission&quot; notion where the<br>
permissions are always the same?<br>
Perhaps it is more useful in systems<br>
with richer TCBs?<br><br>
When I think of &quot;access rights&quot; (e.g.<br>
&quot;write&quot; access to a file), in capability<br>
systems, they exist in the &quot;data&quot; of<br>
the capability (something delivered<br>
to the server/object when an invocation<br>
happens).&nbsp; This is what I've tended<br>
to think of as a &quot;permission&quot;.&nbsp; Of<br>
course that notion is at odds with<br>
MarkM's definition that only gets to<br>
the TCB level.&nbsp; The only &quot;permission&quot;<br>
that a subject would have is the ability<br>
to deliver any such &quot;access bits&quot; (e.g.<br>
capability data) to the server (object).<br><br>
I suppose then that something like &quot;access<br>
right&quot;s in a capability might be referred<br>
to as &quot;authorities&quot; because they are provided<br>
by the action of the object (server<br>
process)?<br><br>
Oh well, they're just words.&nbsp; I hope I've<br>
finally gotten it right.&nbsp; Of course MarkM<br>
goes on to define a whole set of permission<br>
and authority notions:<br>
<img src="cid:.0" width=585 height=535 alt="Emacs!"><br><br>
that still puzzle me some, but I think I won't go<br>
there in this message.&nbsp; Maybe for a face to face<br>
discussion some time.<br><br>
Thanks to everybody for helping me through this (and<br>
in advance for correcting me if I still have it wrong).<br>
Sorry if it was wasted reading for others.<br>
<x-sigsep><p></x-sigsep>
--Jed&nbsp;
<a href="http://www.webstart.com/jed-signature.html" eudora="autourl">
http://www.webstart.com/jed-signature.html</a></body>
</html>