Re: Pony talks about Deny Capabilities
Sylvan Clebsch <[email protected]> Mon, 11 May 2015 18:29:53 +0100
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CADBVgPw0H2uLgWZzWZxUb3ycuJf81XaH1B_Gx3Utqennq7CObw@mail.gmail.com> |
Hi everyone, Firstly, thanks very much for the invitation to talk about Pony and ocap. We are very keen to get this right, and very aware that is it hard and we definitely don't have all the answers. We're keen to incorporate suggestions to get this right. > From: Dan Connolly <[email protected]> > > I'm looking over the standard library for ambient authority... the main(env: Env) gave me hope, but now I see: > > primitive Platform > fun linux(): Bool => compiler_intrinsic > fun osx(): Bool => compiler_intrinsic > fun posix(): Bool => linux() or osx() > fun windows(): Bool => compiler_intrinsic > fun has_i128(): Bool => compiler_intrinsic > fun debug(): Bool => compiler_intrinsic This primitive gives only compile-time platform information. That is, these values are set in stone for a program once it is compiled (they are not checked at runtime), and are used primarily to write cross-platform code. We have included Platform.debug, which is set to true if the Pony program was built without optimisations, but we are considering removing it. Is this form of compile-time information problematic? In general, Pony "primitive" types are ambient, in the sense that when they are constructed, they always return the same value (except for Bool and the numeric types). However, they have no state (no fields, can't be modified in any way), so I hope that, while they are ambient, they provide no authority. > and @os_listen_tcp Pony uses the @ to show when it is using the C-FFI. This is a call into the Pony runtime that wraps platform specific networking calls. Since access to the C-FFI is dangerous, the compiler includes an optional --safe switch, that can be used to specify which packages are allowed to use the C-FFI. That is, which packages are "trusted", for values of trusted that include "we need it, so we have to trust it, even though to be honest we don't trust it". Obviously, access to C breaks the ocap model entirely. However, we're hoping the --safe mechanism gives a usable trust boundary. This is an area we are very keen to have feedback on. > and File new create(path': String) Yeah. File systems. Ugh. This is a huge ambient authority problem, and we don't have a clear idea of how to handle it better. > Maybe it's young enough that they'd be interested to address this? We're very interested indeed! Any help would be hugely appreciated. Kind regards, Sylvan _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk