falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balu Vellanki <bvella...@hortonworks.com>
Subject Re: [Discuss] : Should a non-superuser be allowed to update ACL of feed or process entity
Date Tue, 15 Sep 2015 14:52:47 GMT
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