Re: Pony talks about Deny Capabilities

Ben Laurie <[email protected]> Tue, 12 May 2015 12:57:42 +0100
Newsgroups gmane.comp.capabilities.general
Message-ID <CABrd9SQx6f-iAJmNyAUcSMTxMJeTG7OC+3+-LnKUa70Q_KFLAg@mail.gmail.com>
On 11 May 2015 at 20:46, Sylvan Clebsch <[email protected]> wrote:
> 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.

a) Just because you have a path in hand, doesn't mean you're allowed
to create new files under it. Capsicum is finer grained than that -
and, in fact, file creation is relative to a file descriptor, not a
path.

b) Links can be a problem.

c) .. and things like it can be a problem.

> 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?

Like Mark, I am not sure I understand the question, but in general,
anyone can create new capabilities, right?