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

Sam Mason sam at samason.me.uk
Fri Jun 19 13:06:03 EDT 2009


On Fri, Jun 19, 2009 at 04:45:31PM +0000, Karp, Alan H wrote:
> Rob Meijer wrote:
> > class Copier {
> >   static FileObject sFileA;
> >   static setSourceFile(FileObject a) {
> >      sFileA=a;
> >   }
> >   void copy(FileObject fileb) {
> >      sFileA.seek(0);
> >      fileb.write(sFileA.read());}
> >   }
> > }
> > main (FileObject a,FileObject b, FileObject c){
> >   Copier::setSourceFile(a);
> >   copy_from_a = new Copier();
> >   copy_from_a.copy(b);
> >   copy_from_a.copy(c);
> > }
> 
> In this example, which is similar to MarkM's "cat <in >out" example,
> Alice passes open file handles into the program, giving her the
> opportunity to specify which authorities to use for each argument.
> Hence, this example does not meet my definition of ambient authority.

As I understand it; the point of interest is that the "sFileA" member
variable of the "Copier" class is a static variable.  Therefore,
*within* this program access to this variable implies the presence of
ambient authority.

I'd go further and say that in this example the entirety of the code
runs as a single subject and it's therefore not useful to say that we
have ambient authority---because there's no one there to abuse it.  The
moment the code has the possibility of taking on the role of more than
one subject then we should say that use of this Copier class means we
have a program that uses ambient authority.

>From an engineering perspective it would be nice if all code was written
so that it never relied upon the presence of ambient authority and hence
you don't suddenly have to start worrying about what's going to happen
when you move from one to many subjects.

The reason I'm making such a fuss about the presence of multiple
subjects is otherwise ambient authority seems to be a somewhat vacuous
definition.

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


More information about the cap-talk mailing list