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