Yeah that's the right level of authorization. The Function Author should
get to decide.
Listeners, Loaders and Writers should only require DATA:READ and DATA:WRITE
as appropriate.
It is up to the authors what they do inside of those.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Thu, Sep 14, 2017 at 2:29 PM, Swapnil Bawaskar <sbawas...@pivotal.io>
wrote:

> Indeed, the function author has a higher level of privilege than someone
> who is invoking a function, that is why the proposal here is to let the
> function author choose what level of permissions are required to invoke a
> function.
>
> On Thu, Sep 14, 2017 at 11:20 AM Anilkumar Gingade <aging...@pivotal.io>
> wrote:
>
> > >> 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.
> > > >>
> > > >>
> > >
> > >
> >
>

Reply via email to