[cap-talk] Deep attenuation, typed operations

[Sam Mason]

On Tue, Aug 14, 2007 at 09:22:48PM -0700, Jed Donnelley wrote:
> I definitely think this approach that uses
> [permission,type] pairs in the set to be
> used for the allow-only operation is more
> flexible without loss of generality.
> 
> Did I fail to explain it adequately or perhaps
> there is something that I am still missing
> about it?

I didn't get it the first time you explained it but it makes more sense
now.  Thanks for going into more detail.  I was imagining something
similar to what you've just described, it was the only sensible way
I could make it work and even then I couldn't fit your original
description to it.  The way you've been describing it being typed
I'm assuming that you're going to be using something that could be
translated into an IDL.

I think that to use something like this you're going to have to be more
careful with the interface (depending on how you do the implementation
of course) design.  I could imagine doing this attenuation outside the
file-system code for various reasons (if it was made into a general
purpose facility it could be very nice).  If you did you'd have to be
slightly more careful with the interface design, mainly type casts have
to be made explicit.  For example, say we have the following interfaces:

  interface DirEnt { }

  interface File : DirEnt {
    OctetArray read (long offset, int length);
    void       write (long offset, OctetArray data);
  }

  interface Directory : DirEnt {
    DirEnt open (String name);
    (List DirEnt) readdir ();

    void link (DirEnt file, String name);
    void unlink (String name);
  }

The DirEnt is a placeholder as I've not seen a better way to do a
discriminated union in IDL.

If we wanted to get a read-only version of a directory, we could call
your attenuation routine with [(Directory,open), (Directory,readdir),
(File,read)] and get back a capability to it that only allowed access
to the safe methods.  We have a little problem though, the attenuator
wouldn't know what to do with the DirEnt and would probably be forced
to not allow any method calls to it, even though we know that we really
want to cast it to either a file or a directory to do useful work with
it.  The only way I've seen out of it is to extend DirEnt to be:

  interface DirEnt {
    Directory asDirectory ();
    File      asFile ();
  }

Once you've done this, you can then allow those two methods in the call
to the attenuator and everything should work.  The alternative would
be to add some sort of support for discriminated unions to the IDL
language.

If the attenuation is done inside the file-system then obviously this
wouldn't need to be externalised and everything would just appear to
work.


  Sam