[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Thu, 2007-07-26 at 12:50 +1000, James A. Donald wrote:
> James A. Donald:
>  > > Permissions that need to be durable (need to last
>  > > longer than any program invocation) seldom need to
>  > > be communicable, and permissions that need to be
>  > > communicable seldom need to be durable.
> 
> Jonathan S. Shapiro
>  > This hypothesis neglects something very obvious: when
>  > you "open" a file in a conventional ACL system, what
>  > is happening is that the file system is communicating
>  > a permission to the opening process. That is: durable
>  > permissions *must* be communicable.
>  >
>  > In UNIX, at first glance, the durable authority is
>  > stored as an ACL. The ephemeral authority is stored as
>  > a file descriptor. However, this is an implementation
>  > distraction. What is really going on is that a
>  > full-strength capability to the file (namely: the
>  > device/inode-nr pair) has been stored in the directory
>  > structure. The file system is, in effect, extracting a
>  > full-strength capability from the directory and then
>  > downgrading it according to the restrictions
>  > discovered in the attached ACL.
> 
> I regret I am unable to follow your reasoning.  A file
> handle is *not* durable, for it references a file
> descriptor which is not durable. Neither are window
> handles or process handles.  So an actually existent
> operating system is *not* communicating a durable
> permission when it creates a file handle.  Rather, it
> possesses a durable permission to create transient
> permissions, which can be communicated - which is very
> much what we want a powerbox to do.

Yes. I see that I was insufficiently clear.

The difference between the capability stored in the directory and the
capability granted to a fully authorized user is purely a matter of
internal representation. This aside, they are identical capabilities,
and are therefore equally durable.

This aside, I think there is a hidden flaw in the "capabilities die with
their process" meme. Back when systems had an MTBF of hours or days this
might have been a useful source of protection. Today, we see user
sessions that run for months at a time. Given this, it does not seem
obvious that the temporal scope of a process provides a useful basis for
protection.

> 
>  > However, the question of how long the session should
>  > last is an engineering matter. In a persistent system,
>  > it is completely reasonable to have a session that
>  > survives restarts.
> 
> I unaware of any system with sessions that survive
> restarts in practical use at present.

I can name a few, but I agree that transparent persistence is not in
wide use.

However, modern cell phones have a similar property: they do not reboot.
In fact, my current cell phone has a durable store from which it
reconstructs permissions (among other things) after being restarted.

>   Persistent
> computer languages generally have persistent data, not
> persistent sessions.  Perhaps you refer to something
> other than the environments supported by persistent
> computer languages.

Yes. I was referring to systems that exploit systemwide checkpointing.
These are not presently in commodity use anywhere that I know about, but
they do exist.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC