Is there a requirement of, changing the permission in future time...E.g.
Currently the function has WRITE permission, but needs to be changed to
READ, without re-writing/deploying the function.
In that case, permissions needs to be independent of function
implementation.
-Anil.
On Thu, Aug 17, 2017 at 11:26 AM, Udo Kohlmeyer <ukohlme...@pivotal.io>
wrote:
> In the case of lambda executions... we have no way to annotate the
> lambda...
>
> So maybe the "outer" service call needs to help us... Maybe the security
> framework should automatically prevent the execution of any function is the
> user does not have "DATA:READ"/"DATA:WRITE" or "FUNCTION:EXEC" privileges.
>
> In addition to this, do we need to distinguish between "read" and "write"
> functions?
>
>
> On 8/17/17 10:43, Dan Smith wrote:
>
>> if we get to Lambda-based functions
>>>
>> No if about it, this works right now and we do this in our tests :)
>>
>> ResultCollector rc = getExecution().execute(context ->
>> context.getResultSender().lastResult("done")
>> );
>>
>> -Dan
>>
>>
>> On Thu, Aug 17, 2017 at 9:59 AM, Udo Kohlmeyer <ukohlme...@pivotal.io>
>> wrote:
>>
>> I think there might be more to this than just "Data:READ"/"Data:WRITE".
>>> Why would we not support something like /*@Authorize(hasRole("function
>>> Executor"))*/
>>> or /*@Authorize(requiresPermission("DATA:READ"))*/
>>>
>>> The next question in my mind would be, if we get to Lambda-based
>>> functions, how do we specify authorization credentials then? Annotations
>>> are great to "static" definition on services, not so great for more
>>> "dynamic" execution of stuff...
>>>
>>>
>>>
>>> On 8/17/17 09:29, Dan Smith wrote:
>>>
>>> I like the annotation idea, especially considering that Jared was talking
>>>> about adding a @RegisterableFunction annotation as well. maybe something
>>>> like @ResourcePermission("Data:READ") or something like that?
>>>>
>>>> -Dan
>>>>
>>>> On Thu, Aug 17, 2017 at 8:18 AM, Michael William Dodge <
>>>> mdo...@pivotal.io
>>>> wrote:
>>>>
>>>> What about an annotation for read-only functions or a subinterface off
>>>>
>>>>> org.apache.geode.cache.execute.Function?
>>>>>
>>>>> Sarge
>>>>>
>>>>> On 17 Aug, 2017, at 01:42, Swapnil Bawaskar <sbawas...@pivotal.io>
>>>>> wrote:
>>>>>
>>>>> Discuss fix for GEODE-2817
>>>>>> <https://issues.apache.org/jira/browse/GEODE-2817>
>>>>>>
>>>>>> Currently to execute a function, you will need "data:write"
>>>>>> permission,
>>>>>>
>>>>>> but
>>>>>
>>>>> it really depends on what the function is doing. For example, if a
>>>>>>
>>>>>> function
>>>>>
>>>>> is just reading data, the function author might want users with
>>>>>> DATA:READ
>>>>>> permissions to execute the function. The two options mentioned in the
>>>>>> ticket are:
>>>>>>
>>>>>> 1) externalize SecurityService so that function author can use it in
>>>>>> the
>>>>>> function.execute code to check authorization.
>>>>>> 2) add a method to function interface to tell the framework what
>>>>>>
>>>>>> permission
>>>>>
>>>>> this function needs to execute, so that the framework will check the
>>>>>> permission before executing the function.
>>>>>>
>>>>>> I vote for #2 because, I think, a function author will be able to
>>>>>> easily
>>>>>> discover a method on the Function interface, rather than trying to
>>>>>> look
>>>>>>
>>>>>> for
>>>>>
>>>>> SecurityService.
>>>>>>
>>>>>> I propose that we add the following new method to Function:
>>>>>>
>>>>>> default public List<ResourcePermission> requiredPermissions() {
>>>>>> // default DATA:WRITE
>>>>>> }
>>>>>>
>>>>>> In order to preserve existing behavior, the default required
>>>>>> permission
>>>>>> would be DATA:WRITE.
>>>>>>
>>>>>>
>>>>>
>
