Also, I think I may have missed this but does READ imply you also have DESCRIBE? A reader will need access to both read offsets (to determine their own initial position) as well as commit offsets. Currently, though fetching offsets is under DESCRIBE only and commit offsets is under READ. If READ=>DESCRIBE are there any other implied permissions like that?
-Jay On Tue, Apr 21, 2015 at 1:59 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > Hey Parth, > > Great write-up! > > One super minor thing: could we change the "EDIT" permission to be called > "ALTER"? The request name in KIP-4 is Alter and the command line tool has > always been alter (or we could go the other way and change those to EDIT). > Not sure that one is any better than the other but consistency is always > nice. > > -Jay > > On Tue, Apr 21, 2015 at 9:06 AM, Jun Rao <j...@confluent.io> wrote: > >> Harsha, Parth, >> >> Thanks for the clarification. This makes sense. Perhaps we can clarify the >> meaning of those rules in the wiki. >> >> Related to this, it seems that we need to support wildcard in cli/request >> protocol for topics? >> >> Jun >> >> On Mon, Apr 20, 2015 at 9: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. >> > > >> > >> > >> > >
