Thanks for clarifying the logic. I'm +0 on the deny thing. IMO, its not really needed, but if you think its important, I don't object to having it in.
Gwen On Mon, Apr 20, 2015 at 7:07 PM, Parth Brahmbhatt <pbrahmbh...@hortonworks.com> wrote: > The iptables on unix supports the DENY operator, not that it should > matter. The deny operator can also be used to specify ³allow user1 to READ > from topic1 from all hosts but host1,host2². Again we could add a host > group semantic and extra complexity around that, not sure if its worth it. > In addition with DENY operator you are now not forced to create a special > group just to support the authorization use case. I am not convinced that > the operator it self is really all that confusing. There are 3 practical > use cases: > - Resource with no acl what so ever -> allow access to everyone ( just for > backward compatibility, I would much rather fail close and force users to > explicitly grant acls that allows access to all users.) > - Resource with some acl attached -> only users that have a matching allow > acl are allowed (i.e. ³allow READ access to topic1 to user1 from all > hosts², only user1 has READ access and no other user has access of any > kind) > - Resource with some allow and some deny acl attached -> users are allowed > to perform operation only when they satisfy allow acl and do not have > conflicting deny acl. Users that have no acl(allow or deny) will still not > have any access. (i.e. ³allow READ access to topic1 to user1 from all > hosts except host1 and host², only user1 has access but not from host1 an > host2) > > I think we need to make a decision on deny primarily because with > introduction of acl management API, Acl is now a public class that will be > used by Ranger/Santry and other authroization providers. In Current design > the acl has a permissionType enum field with possible values of Allow and > Deny. If we chose to remove deny we can assume all acls to be of allow > type and remove the permissionType field completely. > > Thanks > Parth > > On 4/20/15, 6:12 PM, "Gwen Shapira" <gshap...@cloudera.com> wrote: > >>I think thats how its done in pretty much any system I can think of. >> >
