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?