[cap-talk] Selling capabilities programming
Jonathan S. Shapiro
shap at eros-os.com
Wed Jul 25 23:50:59 EDT 2007
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
> > 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
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.
> 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.
Jonathan S. Shapiro, Ph.D.
The EROS Group, LLC
More information about the cap-talk