>> from reaching into internal classes
If thats the case; one could do anything, even with read permission...Isn't
it...
On Thu, Sep 14, 2017 at 10:43 AM, Jared Stewart <jstew...@pivotal.io> wrote:
> 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.
> >>
> >>
>
>
