Changed Edit to Alter. I did not think about it that way but Sriharsha raised the same point in a private conversation. I did not think about it that way but I agree it makes sense. If no one objects I think in default implementation we can infer that if user have READ or WRITE access he gets DESCRIBE for free.
Thanks Parth On 4/21/15, 2:04 PM, "Jay Kreps" <jay.kr...@gmail.com> wrote: >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. >>> > > >>> > >>> > >>> >> >>
