[cap-talk] Persistence as a cap value

[Jed Donnelley]

At 09:59 PM 3/13/2008, Pierre THIERRY wrote:
>Scribit James A. Donald dies 14/03/2008 hora 11:45:
> > Jed Donnelley wrote:
> >> I wonder if you could give an example of a capability that made sense
> >> to issue/communicate as non-persistent? [...]
> > The capability to access a particular file: my word processor should
> > not be able to open or modify any @#$%^&* file it pleases,
>
>I don't see how persistence of a file capability could enable the
>process holding it to access "any file it pleases". If the process
>receives from a powerbox a persistent read/write capability to a file X,
>at each restart of the system it will only be able to read and write
>file X.
>
>And if I have started a dozen editors on source files and three help
>viewers on various documentations, I don't want to have to reopen them
>on restart. I don't even want to have to remember what was open.
>
>Persistently,
>Pierre

Heh.  I of course agree.

I hope there is no confusion that persistence = permanence.
Persistent capabilities can of course be revokable.  As I noted,
I suggested to Mark Seaborn (sorry if this is old news) that
PLASH revoke capabilities (close files, if that's possible)
after an application runs - in effect revoking the capabilities.

Let me try to understand Alan's suggested applications for
non persistent capabilities (below).  I hope I'm not responding
to these out of sequence.  I acknowledged that to me it makes
sense to have non persistent capabilities iff all the processes
that can operate on the capabilities have the same lifetime
as the capabilities (i.e. they disappear together).

At 11:31 AM 3/13/2008, Karp, Alan H wrote:
>Jed wrote:
> >
> > I wonder if you could give an example of a capability that made
> > sense to issue/communicate as non-persistent?
>
>Jonathan's example of a remote user is one.  That user can create 
>transient resources (think temp files) and their corresponding 
>capabilities that all vanish when the connection is broken.  Those 
>capabilities are useful to that client even if they're not sent to anyone else.

Sorry, but I don't understand the value of the above example.

I believe temp files (if used reasonably) fall into the category of
tying the resource that only lasts until a restart with a process
with the same property.  If the program runs and generates a
temp file and the system restarts before the program outputs
to permanent files, everything is lost.  You don't have to
clean up the "temp" files is the only value I see there.

I'm sorry, but I may need some more explanation to understand
the above example.  For example, a connection can be lost without
a system restart (e.g. network partition or timeout).  In that
case I guess (from the above) that capabilities are invalidated,
but not by a system restart.  The above suggests another sort
of non persistent capability tied to connection longevity.

To me that would also make sense iff the processing resource
was also tied to the connection longevity.

>The transient capabilities may be sent to another client for later 
>use.  The sender has no control over when or whether the recipient 
>will use the capability.  If the capability is sent as part of a 
>transaction, the guarantee that the capability disappears on system 
>restart makes supporting transactional semantics easier.

The above again suggests a capability that is tied to
a connection.

>Transient capabilities are also useful for the recipient.  In Client 
>Utility, the c-list was actually stored in a set of "frames".  A 
>received capability stored in a non-persistent frame would not 
>appear in the client's c-list after the frame vanished.  That 
>allowed a programmer to control the permission state when the 
>program was restarted.


And if the capability was communicated before the frame vanished?

Are there examples (these if I've misunderstood or others) where
non persistent capabilities are valuable even when they are
not constrained to processes that disappear when the capabilities
do?

Hmmm.  Just by the constraint of my question, if the
capabilities disappear before the processes, then a process may
access an invalid capability - seemingly unnecessarily?  If the
processes disappear before the capabilities, well no loss - as
with persistent capabilities.  Maybe there is still something
I'm missing.

I believe the Unix open file descriptor as capability is an
example where the non persistence of the capability might be
tied to a process reset (e.g. on system restart), but
unfortunately not to the proper process reset.  In the
example of a Trojan horse application, the application
could send an open file descriptor out through a pipe
to some other user process that could, in principle,
keep accessing the file until the system was restarted.

--Jed  http://www.webstart.com/jed-signature.html