[cap-talk] Selling capabilities programming

[James A. Donald]

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.

Indeed the idea of a powerbox is often illustrated by
comparing "cat" with "cp" - which implies that existing
systems can do what is needed, and should do more things
the way they do "cat", and less things the way they do
"cp".

 > 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.  Persistent
computer languages generally have persistent data, not
persistent sessions.  Perhaps you refer to something
other than the environments supported by persistent
computer languages.

Persistent computer languages are usually tightly
coupled to databases, thus in practice their code
usually implements transactions that are either
completed within a short time, or rolled back within a
short time.  The intent is to simulate the effect of
sessions of zero or extremely short duration, rather
than support sessions of indefinitely long duration, let
alone sessions that survive restarts.  A language that
supports persistent data frequently expects a large
number of brief invocations, sequentially or in
parallel, with data persisting between invocations - or
at least invocations that may be usefully thought of as
brief even if in practice they involve massively
parallel computations with large masses of data that
take quite a long time.