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: [email protected] > To: [email protected] > 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" <[email protected]> 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 > ><[email protected]> 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 < > >[email protected]> 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 <[email protected]> > >> 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 < > >> [email protected]> > >> > 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 > >> > > > > > > >
