I tend to agree with Parth's point here. Most ACL systems I run into have deny and allow. In general, you have a default policy of allow, then you follow your rules stopping at the first line that matches. If you would like a default deny policy, you have a bunch of allow rules and your last rule is "deny all". This says "everyone listed is allowed. Everyone else is denied." If you instead want a default allow, you have a list of deny rules and the last rule is "allow all". This says "everyone listed is denied. Everyone else is allowed".
I think leaving out a full rule set would be a mistake, as it makes the assumption that you know what all the use cases are. I think all it will really mean is that we will see a KIP before long to fix it. -Todd > On Apr 20, 2015, at 7:13 PM, Gwen Shapira <gshap...@cloudera.com> wrote: > > 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. >>
