There is nothing to prevent code in a function that's executing on a server
from reaching into internal classes and bypassing the public region APIs. I
think a function's author should ultimately determine the permissions required
to execute it.
> On Sep 14, 2017, at 10:34 AM, Anilkumar Gingade <aging...@pivotal.io> wrote:
>
> When a function is accessing/modifying region; the function will be doing
> so by region apis, don't we have credential check with region apis; if not
> can we add those checks here...instead of having it in the function...
>
> -Anil.
>
>
>
> On Wed, Sep 13, 2017 at 11:22 AM, Jared Stewart <jstew...@pivotal.io> wrote:
>
>> After some more investigation into the implementation details, here is our
>> updated proposal to add to the Function interface:
>>
>> default Collection<ResourcePermission>
>> getRequiredPermissions(Optional<String>
>> onRegion) {
>> return Collections.singletonList(ResourcePermissions.DATA_WRITE);
>> }
>>
>> This method can be overridden by Function authors who want to require
>> permissions other than DATA:WRITE.. The onRegion parameter will be present
>> only when a Function is executed via FunctionService.onRegion, and is
>> intended to allow Function authors to require different permissions
>> depending on the Region which Function will be executed on. We pass the
>> region name into this method rather than the full FunctionContext because
>> the latter would be much more expansive to implement.
>>
>> Any feedback is appreciated.
>>
>> Thanks,
>> Jared
>>
>>> On Aug 17, 2017, at 1:42 AM, 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.
>>
>>
