[cap-talk] "ambient authority" on wiki.erights.org
David Wagner
daw at cs.berkeley.edu
Fri Jun 12 02:00:44 EDT 2009
Matej Kosik wrote:
> [...] would be relevant if "ambient authority" was somehow inherently
> connected with "excess authority" which is not true.
I don't know whether it's necessarily true in principle, but it seems
to be true enough in practice: in practice, ambient authority seems to
lead to excess authority. For instance, ambient authority means that
each part of the program you're running will have full authority (the
union of all the authority that any part might ever need). For many
parts of the program, this is more than the part needs.
> The general form of ACLs (where we could specify permitted operations
> on all objects for all subjects independently) is sufficient to avoid
> it while it still falls into "ambient authority system" category.
Maximally fine-grained ACLs still provides excess authority, for
two reasons. (1) Each single instance of the program receives the
union of all authority that any running instance will ever need.
(2) Each part of the program receives the union of all authority that
any part of the program needs.
Think of "cp foo.txt bar.txt" vs "cat < foo.txt > bar.txt", for instance
(an example I learned from Mark Miller, if I remember correctly). "cp"
can only be implemented with ambient authority, and if you try to set
the ACLs for "cp", you find that it needs authority to all of your files
(because it needs to be able to handle any file you ask it to copy). This
is way more than any single running instance of "cp" needs; any single
instance only needs read access to its first argument and write access
to its second argument, but in an ACL system every instance receives
full authority to all of your files. I can't see any way out of that.
I don't see how fully general fine-grained ACLs would change anything.
More information about the cap-talk
mailing list