Re: Pony talks about Deny Capabilities

On 11 May 2015 at 20:04, Mark Miller <[email protected]> wrote:
>
> Agree with Scott. But see also how previous ocap languages running on
unmodified legacy non-ocap OSes handled these issues, including E, Joe-E,
and Emily. See also how Caja/SES handles access to ambient browser
authority such as the DOM.

E's approach (assuming I understand it correctly, which is a big
assumption) of only allowing a File object to be created relative to a
previously existing File object is the one I've been looking at (funnily
enough, just this past weekend). I was considering a separate sort of
object that encapsulated a Path, which could be examined, split, etc as
usual, but a new Path would have to be a concatenation of an existing Path
and additional data.

This would allow a "root" Path to be passed in the Env to the Main actor,
with that actor then able to control access in the expected way. Is that
the approach you are advocating, Mark?

However, Scott's points about atomic creation, etc, would still be
unaddressed. Scott, thanks for the pointer to Shill, I'm sorry to say I
hadn't come across it previously. I'll read up!

Another issue I've been thinking about is that if a file system sandbox is
a capability, and perhaps network access (though addresses are less
usefully hierarchical - although DNS perhaps is), then is some more general
mechanism for a package introducing a new "root" capability (not previously
encoded in Env, but necessarily not ambient) needed? Is there existing work
in this area?

-s

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk