[cap-talk] caps tried and rejected for AMQP

[Sandro Magi]

I only have a second to reply, but Mark Miller, Jed Donnelly and Alan
Karp devised just such an ACL-over-caps system, called Horton:

http://www.erights.org/elib/capability/horton/

An implementation depends on certain primitives that would also need to
be present in your DSL, but nothing unreasonable IIRC.

Sandro

Ben Hood wrote:
> Hi,
> 
> If you're really interested in the real reason why after consideration  
> ACLs got the nod ahead of caps in RabbitMQ, I suggest that you ask  
> this question on the Rabbit mailing list. I can only give you my  
> biased view because I was the one who proposed caps in Rabbit in the  
> first place.
> 
> Maybe a little context might help:
> 
> The 0-8 AMQP spec originally mandated a conceptually flawed ACL  
> mechanism in the protocol. Rabbit committed the schoolboy error of  
> treating this as gospel and actually implemented it, only to find out  
> that the other implementors decided to abstain. Hence the working  
> group dropped ACLs from the protocol. So we deleted that code from our  
> source tree.
> 
> In the meantime, many administrators of Rabbit were complaining that  
> they had no fine grained mechanism to control access to the broker. In  
> response to this, we began to devise a proprietary ACL mechanism  
> orthogonal to the protocol. As this was happening, I began to research  
> and protoype the use of caps to acheive the same end. The result of  
> this was some running code in the broker and the article that is the  
> subject of this thread.
> 
> IMHO the main disadvantages of the caps approach are:
> 
> - It would most probably require a minor revision to the protocol to  
> become compliant;
> - You'd have to augment every client library that wanted to take  
> advantage of access control - only a few clients are actually  
> maintained by Rabbit;
> - No users were asking for something like caps - they just wanted ACLs;
> - The conceptual overhead may have been too great for a significant  
> number of users;
> - Some intelligent people remained unconvinced about the merits of caps;
> - It would have confused a lot of sysadmins - they generally prefer  
> ACLs and they were the ones asking to have access control put back;
> 
> Having said that, there were some positive touchpoints:
> 
> - ACLs require that the broker implementors decide a priori what  
> catagories of access control are required rather than deferring this  
> to the application developers;
> - Caps allow arbitrarily fine access control (see this thread for a  
> relevant example: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-August/004389.html 
> );
> - Caps facilate distributed access control;
> - Users can define their own access semantics a posteriori;
> - (Personally) I like the meta-circularity it would bring;
> 
> If you were to design it carefully, you could choose any number of  
> languages to express caps and still remain protocol compliant. I used  
> AMQP as the DSL for caps in my prototype, but I could have defined my  
> own language or even gone for something Turing complete.
> 
> Furthermore, I am a complete n00b when it comes to caps - I may well  
> have missed the whole point in my prototype - nobody has ever  
> commented on the implementation, so it's hard to tell whether it makes  
> sense or not.
> 
> I guess that if anybody in the caps community did want evangelize it's  
> adoption in Rabbit, the best thing to do IMHO is to provide us with a  
> workable concept of how to layer ACLs on top of capabilities so that  
> you have the best of both worlds. Bear in mind that whilst the Rabbit  
> team is receptive to new ideas, we are run off our feet implementing  
> other features, so working code will speak louder than anything else.
> 
> I hope that this is helpful,
> 
> Cheers,
> 
> Ben
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk