[cap-talk] "ambient authority" on wiki.erights.org

[Sam Mason]

On Mon, Jun 15, 2009 at 08:49:19PM +0100, Toby Murray wrote:
> On Mon, 2009-06-15 at 19:55 +0100, David-Sarah Hopwood wrote:
> > Karp, Alan H wrote:
> > > David-Sarah Hopwood wrote:
> > >> The dereference of the static variable represents use of ambient authority.
> > >>
> > > No it doesn't.  The object is referenced explicitly.
> > 
> > The object dereferenced by name, from a global namespace (assuming
> > we are considering global static variables), without specifying any
> > additional permission that grants the authority to dereference this
> > variable.
> > 
> > There is no essential difference between this and the fopen+fread example:
> > in both cases you have an ambient dereferencing operation, followed by a
> > non-ambient use of the obtained reference.
> 
> But the authority used in the initial dereference is not ambient.
> Whatever the name refers to you have the permission to access.

I don't think this is a useful distinction; the thing of interest seems
to be your frame of reference.  If you have trusted and untrusted
modules within a single process then you need to be sure that global
variables convey no authority.  If you're modeling/thinking about a
larger system then the individual components should be classed as
trusted and untrusted, and it should be ensured that there's no ambient
authority shared between modules.

> I agree with Alan. I'd see an "import <module>" as an ambient operation,
> sure, but global variables are simply capabilities available in every
> scope (like E's SafeScope or GlobalScope or whatever).

I've not programmed E, so my comments may be a little out, but surely
importing a module should convey no authority to the code that imports
it so I fail to see why this is a useful example.  It uses things
ambiently, but the system should have been designed so that no authority
is conveyed as a result.

-- 
  Sam  http://samason.me.uk/