[cap-talk] More Heresey: ACLs not inherently bad

[Jonathan S. Shapiro]

Thanks, Alan. I've been feeling a little bit like a lone Husky baying at
the moon on this. It's reassuring to know that the moon in question
isn't just a stage prop from central stores. :-)

shap

On Wed, 2008-09-17 at 16:06 +0000, Karp, Alan H wrote:
> Shap wrote:
> >
> > 1. Jonathan is prepared to accept a hybrid system for the sake of
> > compatibility, and then go on to avoid building any of the system layer
> > security on the ACL mechanism.
> >
> > 2. I still haven't heard a credible answer to the sharing problem that
> > doesn't reconstruct ACLs.
> >
> All of your examples on the complexity of the problem are related to restricting access to parts of the shared graph.  In that case, capabilities can be used to grant permissions, while ACLs are used to deny the right of certain principals to use some of those permissions, an example of voluntary oblivious compliance.  The control you've been asking for with easy delegation and no confused deputy.  In order to make such a scheme work, you need a reliable way to pass the identity of the invoker, but ACL systems must have that anyway.  When using file handles as capabilities, I think the only change to the infrastructure is to include in the file handle data structure a reference the ACL for the file.
> 
> These are real world issues.  I've just started discussions with some Hadoop folks about managing access rights.  They are finding managing the ACLs unworkable and are looking for something else.  I'm proposing an authorization based approach (whether or not it's capabilities depends on details of their infrastructure), and the issues Jonathan is raising will definitely come up in the discussion.
> 
> ________________________
> Alan Karp
> Principal Scientist
> Virus Safe Computing Initiative
> Hewlett-Packard Laboratories
> 1501 Page Mill Road
> Palo Alto, CA 94304
> (650) 857-3967, fax (650) 857-7029
> http://www.hpl.hp.com/personal/Alan_Karp
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk