falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Venkat Ranganathan <vranganat...@hortonworks.com>
Subject Re: [Discuss] : Should a non-superuser be allowed to update ACL of feed or process entity
Date Wed, 16 Sep 2015 01:21:09 GMT
We discussed this earlier as part of one of our regression QE issues failing when we were doing
the proxy user.   Yes, agreed that we need this to be fixed by fixing ACL handling in general.
  I would like to target it for post 0.8, given that we have a flurry of features for 0.8

Thanks

Venkat




On 9/15/15, 8:54 AM, "Srikanth Sundarrajan" <sriksun@hotmail.com> wrote:

>IMHO, Only owner should be allowed to change the ownership on the entity, not a member
of the group. Removing the ACL from the entity would be the right way forward to solve for
this. ACLs in the entity is too messy.
>
>Regards
>Srikanth Sundarrajan
>
>> Subject: Re: [Discuss] : Should a non-superuser be allowed to update ACL of feed
or process entity
>> From: bvellanki@hortonworks.com
>> To: dev@falcon.apache.org
>> Date: Tue, 15 Sep 2015 14:52:47 +0000
>> 
>> Based on discussion - we all seem to agree that
>> - Only superuser should change ownership
>> - Falcon team should implement the functionality for permissions part of
>> ACL. 
>> 
>> Balu
>> 
>> On 9/14/15, 10:45 PM, "Peeyush Bishnoi" <bpeeyush@yahoo.co.in> wrote:
>> 
>> >Balu,
>> >Thanks for initiating the discussion.
>> >I am of the opinion here is that ACL of feed/process entity should work
>> >similarly to the UNIX-like system.
>> >If user1 has not set the permission for group writable , then user2
>> >should not be allowed to updateACL of feed or process entity. If user1
>> >has set the permission for group writable purposefully, then user2 should
>> >alsoupdate as per the agreement between user1 and user2 (collaborative
>> >work) as they belong to same group.
>> >
>> >Thanks,---Peeyush
>> >
>> >
>> >
>> > 
>> >
>> >
>> >     On Tuesday, 15 September 2015 10:23 AM, Sandeep Samudrala
>> ><sandysmdl@gmail.com> wrote:
>> >   
>> >
>> > I agree with above point to handle submission time. But again an entity
>> >can
>> >be submitted and scheduled with different users, in which case the user
>> >with which schedule is ran will be used. We might have to handle even
>> >scheduling part. I think rather than handling ACL at various levels, the
>> >whole ACL can be improved as part of FALCON-1367
>> ><https://issues.apache.org/jira/browse/FALCON-1367>.
>> >
>> >On Tue, Sep 15, 2015 at 10:14 AM, pavan kumar Kolamuri <
>> >pavan.kolamuri@gmail.com> wrote:
>> >
>> >> Even i agree that user2 shouldn't update/delete/suspend the entity, but
>> >>we
>> >> should be consistent across all API's for the same. As of now submit is
>> >> allowed if user belongs to the same group of ACL owner group right ?
>> >>Should
>> >> we also change this behaviour to make sure only ACL owner should be
>> >>allowed
>> >> to submit ?
>> >>
>> >> On Tue, Sep 15, 2015 at 9:58 AM, Pallavi Rao <pallavi.rao@inmobi.com>
>> >> wrote:
>> >>
>> >> > Agree that "user2" shouldn't be allowed to just update the entity and
>> >> > change the ownership. All the more reason to have a separate Auth API,
>> >> > rather than embed the ACL in the entity itself. Such issues can be
>> >> handled
>> >> > in a much cleaner way.
>> >> >
>> >> > Regards,
>> >> > Pallavi
>> >> >
>> >> > On Tue, Sep 15, 2015 at 3:12 AM, Balu Vellanki <
>> >> bvellanki@hortonworks.com>
>> >> > wrote:
>> >> >
>> >> > > Hi Team,
>> >> > >
>> >> > > Today, Feed/Process entities have ACL with owner and group. Support
>> >>for
>> >> > > permissions is not implemented yet. Any user who is the owner
OR who
>> >> > > belongs to the group can update/delete/suspend the entity.
>> >> > >
>> >> > > If two users "user1" and "user2" belong to same group "users"
and
>> >>the
>> >> > > falcon entity ACL is <ACL owner="user1" group="users"
>> >>permission="*"/>,
>> >> > > then user2 can update the falcon entity and claim ownership of
this
>> >> > entity.
>> >> > > I believe that user2 should not be allowed to do so unless it
is
>> >> > > superuser.  Similar behavior is not allowed in HDFS.  Please
>> >>comment if
>> >> > you
>> >> > > disagree.
>> >> > >
>> >> > > https://issues.apache.org/jira/browse/FALCON-1340
>> >> > >
>> >> > > Thanks
>> >> > > Balu Velalnki
>> >> > >
>> >> >
>> >> > --
>> >> > _____________________________________________________________
>> >> > The information contained in this communication is intended solely
for
>> >> the
>> >> > use of the individual or entity to whom it is addressed and others
>> >> > authorized to receive it. It may contain confidential or legally
>> >> privileged
>> >> > information. If you are not the intended recipient you are hereby
>> >> notified
>> >> > that any disclosure, copying, distribution or taking any action in
>> >> reliance
>> >> > on the contents of this information is strictly prohibited and may
be
>> >> > unlawful. If you have received this communication in error, please
>> >>notify
>> >> > us immediately by responding to this email and then delete it from
>> >>your
>> >> > system. The firm is neither liable for the proper and complete
>> >> transmission
>> >> > of the information contained in this communication nor for any delay
>> >>in
>> >> its
>> >> > receipt.
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Regards
>> >> Pavan Kumar Kolamuri
>> >>
>> >
>> >
>> >  
>> 
> 		 	   		  
Mime
View raw message