You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Swapnil Bawaskar <sb...@pivotal.io> on 2017/08/17 08:42:05 UTC
[DISCUSS] authorizing function execution
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.
Re: [DISCUSS] authorizing function execution
Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <uk...@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 <uk...@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 <
>>>> mdodge@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 <sb...@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.
>>>>>>
>>>>>>
>>>>>
>
Re: [DISCUSS] authorizing function execution
Posted by Patrick Rhomberg <pr...@pivotal.io>.
I like the simplicity of the annotation, but that simplicity has some
problems other than just playing nicely with lambdas. If permission
required is dependent on function parameters or cluster state, it can't
(currently) be resolved as part of the annotation. We already work-around
this in a few places where we check if a cache is persistent before
requiring CLUSTER:WRITE:DISK.
On Thu, Aug 17, 2017 at 1:56 PM, Jared Stewart <js...@pivotal.io> wrote:
> We already have a similar annotation that we use internally to secure GFSH
> commands:
> @ResourceOperation(resource = Resource.DATA, operation = Operation.MANAGE)
> public Result createRegion(
> One option might be to move this annotation into a public package and to
> enforce it if present on Functions. The only caveat is that we would need
> to extend the annotation a bit to support multiple permissions (right now
> it only supports a single permission like "DATA:READ", but not e.g.
> "DATA:READ and CLUSTER:READ" ). In any case, the permissions required to
> execute a function should not change from what they are today unless a
> function author explicitly specifies the permissions that should be
> required. (Whether in the form of an annotation, a method, or whatever
> form we decide on.)
>
> - Jared
> > On Aug 17, 2017, at 1:35 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > Y'all should checkout PicketLink (now KeyCloak) and how they handle
> this. I
> > used this heavily in the past with JBoss AS. It supports annotation and
> > inline restrictions. Also supports EL but that's for another day. While I
> > am not advocating today (maybe tomorrow) that we witch to PicketLink but
> > looking at other projects that have solved with application server domain
> > issue may help us make better choices.
> >
> >
> > http://docs.jboss.org/picketlink/2/latest/reference/
> html/Checking_for_Permissions.html
> >
> >
> > On Thu, Aug 17, 2017 at 1:27 PM Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
> >
> >> I don't think we should give a user explicit permissions to change the
> >> authorization levels for their function.
> >>
> >> I think that the SecurityService should have some knowledge about
> >> authorization levels on a per-user or per-role. That would check the
> >> authorization level on a per-user basis for every function. This might
> >> require a more fine grained authorization mechanism to be role-based or
> >> more specific user authorization settings should be set up that certain
> >> users can only execute specific functions, or not execute functions at
> >> all...
> >>
> >> In addition to that, there are many functions that could feasibly be
> >> read-only. Thus "DATA:READ" permissions would be sufficient... but the
> >> current system does not protect itself to access a region and execute a
> >> "WRITE" operation, so we are left with the lowest common denominator.
> >>
> >> --Udo
> >>
> >>
> >> On 8/17/17 12:10, Swapnil Bawaskar wrote:
> >>> So, it sounds like if we did #1 above: i.e:
> >>> 1) externalize SecurityService so that function author can use it in
> the
> >>> function.execute code to check authorization.
> >>>
> >>> we could get this to work with lambdas:
> >>> ResultCollector rc = getExecution().execute(context ->
> >>> context.getCache().getSecurityService().authorizeRead();
> >>> // perform read
> >>> context.getResultSender().lastResult(result)
> >>> );
> >>>
> >>> Udo,
> >>> I think there are plenty of use cases where a user would only have
> >>> privileges to read data, if this reading of data involves a function,
> >> that
> >>> user will need write privileges too.
> >>>
> >>> On Thu, Aug 17, 2017 at 11:26 AM Udo Kohlmeyer <uk...@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 <
> ukohlmeyer@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("functionExecutor"))*/
> >>>>>> 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 <
> >>>> mdodge@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 <sbawaskar@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.
> >>>>>>>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] authorizing function execution
Posted by Jared Stewart <js...@pivotal.io>.
We already have a similar annotation that we use internally to secure GFSH commands:
@ResourceOperation(resource = Resource.DATA, operation = Operation.MANAGE)
public Result createRegion(
One option might be to move this annotation into a public package and to enforce it if present on Functions. The only caveat is that we would need to extend the annotation a bit to support multiple permissions (right now it only supports a single permission like "DATA:READ", but not e.g. "DATA:READ and CLUSTER:READ" ). In any case, the permissions required to execute a function should not change from what they are today unless a function author explicitly specifies the permissions that should be required. (Whether in the form of an annotation, a method, or whatever form we decide on.)
- Jared
> On Aug 17, 2017, at 1:35 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> Y'all should checkout PicketLink (now KeyCloak) and how they handle this. I
> used this heavily in the past with JBoss AS. It supports annotation and
> inline restrictions. Also supports EL but that's for another day. While I
> am not advocating today (maybe tomorrow) that we witch to PicketLink but
> looking at other projects that have solved with application server domain
> issue may help us make better choices.
>
>
> http://docs.jboss.org/picketlink/2/latest/reference/html/Checking_for_Permissions.html
>
>
> On Thu, Aug 17, 2017 at 1:27 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
>> I don't think we should give a user explicit permissions to change the
>> authorization levels for their function.
>>
>> I think that the SecurityService should have some knowledge about
>> authorization levels on a per-user or per-role. That would check the
>> authorization level on a per-user basis for every function. This might
>> require a more fine grained authorization mechanism to be role-based or
>> more specific user authorization settings should be set up that certain
>> users can only execute specific functions, or not execute functions at
>> all...
>>
>> In addition to that, there are many functions that could feasibly be
>> read-only. Thus "DATA:READ" permissions would be sufficient... but the
>> current system does not protect itself to access a region and execute a
>> "WRITE" operation, so we are left with the lowest common denominator.
>>
>> --Udo
>>
>>
>> On 8/17/17 12:10, Swapnil Bawaskar wrote:
>>> So, it sounds like if we did #1 above: i.e:
>>> 1) externalize SecurityService so that function author can use it in the
>>> function.execute code to check authorization.
>>>
>>> we could get this to work with lambdas:
>>> ResultCollector rc = getExecution().execute(context ->
>>> context.getCache().getSecurityService().authorizeRead();
>>> // perform read
>>> context.getResultSender().lastResult(result)
>>> );
>>>
>>> Udo,
>>> I think there are plenty of use cases where a user would only have
>>> privileges to read data, if this reading of data involves a function,
>> that
>>> user will need write privileges too.
>>>
>>> On Thu, Aug 17, 2017 at 11:26 AM Udo Kohlmeyer <uk...@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 <uk...@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("functionExecutor"))*/
>>>>>> 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 <
>>>> mdodge@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 <sb...@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.
>>>>>>>>>
>>>>
>>
>>
Re: [DISCUSS] authorizing function execution
Posted by Jacob Barrett <jb...@pivotal.io>.
Y'all should checkout PicketLink (now KeyCloak) and how they handle this. I
used this heavily in the past with JBoss AS. It supports annotation and
inline restrictions. Also supports EL but that's for another day. While I
am not advocating today (maybe tomorrow) that we witch to PicketLink but
looking at other projects that have solved with application server domain
issue may help us make better choices.
http://docs.jboss.org/picketlink/2/latest/reference/html/Checking_for_Permissions.html
On Thu, Aug 17, 2017 at 1:27 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
> I don't think we should give a user explicit permissions to change the
> authorization levels for their function.
>
> I think that the SecurityService should have some knowledge about
> authorization levels on a per-user or per-role. That would check the
> authorization level on a per-user basis for every function. This might
> require a more fine grained authorization mechanism to be role-based or
> more specific user authorization settings should be set up that certain
> users can only execute specific functions, or not execute functions at
> all...
>
> In addition to that, there are many functions that could feasibly be
> read-only. Thus "DATA:READ" permissions would be sufficient... but the
> current system does not protect itself to access a region and execute a
> "WRITE" operation, so we are left with the lowest common denominator.
>
> --Udo
>
>
> On 8/17/17 12:10, Swapnil Bawaskar wrote:
> > So, it sounds like if we did #1 above: i.e:
> > 1) externalize SecurityService so that function author can use it in the
> > function.execute code to check authorization.
> >
> > we could get this to work with lambdas:
> > ResultCollector rc = getExecution().execute(context ->
> > context.getCache().getSecurityService().authorizeRead();
> > // perform read
> > context.getResultSender().lastResult(result)
> > );
> >
> > Udo,
> > I think there are plenty of use cases where a user would only have
> > privileges to read data, if this reading of data involves a function,
> that
> > user will need write privileges too.
> >
> > On Thu, Aug 17, 2017 at 11:26 AM Udo Kohlmeyer <uk...@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 <uk...@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("functionExecutor"))*/
> >>>> 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 <
> >> mdodge@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 <sb...@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.
> >>>>>>>
> >>
>
>
Re: [DISCUSS] authorizing function execution
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
I don't think we should give a user explicit permissions to change the
authorization levels for their function.
I think that the SecurityService should have some knowledge about
authorization levels on a per-user or per-role. That would check the
authorization level on a per-user basis for every function. This might
require a more fine grained authorization mechanism to be role-based or
more specific user authorization settings should be set up that certain
users can only execute specific functions, or not execute functions at
all...
In addition to that, there are many functions that could feasibly be
read-only. Thus "DATA:READ" permissions would be sufficient... but the
current system does not protect itself to access a region and execute a
"WRITE" operation, so we are left with the lowest common denominator.
--Udo
On 8/17/17 12:10, Swapnil Bawaskar wrote:
> So, it sounds like if we did #1 above: i.e:
> 1) externalize SecurityService so that function author can use it in the
> function.execute code to check authorization.
>
> we could get this to work with lambdas:
> ResultCollector rc = getExecution().execute(context ->
> context.getCache().getSecurityService().authorizeRead();
> // perform read
> context.getResultSender().lastResult(result)
> );
>
> Udo,
> I think there are plenty of use cases where a user would only have
> privileges to read data, if this reading of data involves a function, that
> user will need write privileges too.
>
> On Thu, Aug 17, 2017 at 11:26 AM Udo Kohlmeyer <uk...@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 <uk...@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("functionExecutor"))*/
>>>> 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 <
>> mdodge@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 <sb...@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.
>>>>>>>
>>
Re: [DISCUSS] authorizing function execution
Posted by Udo Kohlmeyer <ud...@apache.org>.
When we speak of "users" here, do we mean normal developers or
"administrational users"?
My concern is that given the current functionality of "deploy jar" it
would be too easy to deploy a jar, containing a function that has
"relaxed" user permissions. Which would allow them to execute ANY
function without being able to stop them.
I believe that the security-level for any function should have a default
security level and then a power-user or admin needs to override the
security-level for that function on a per-user, per-role or resource-level.
At least with this approach, the changes to security-level overrides can
be logged and audited.
--Udo
On 8/21/17 08:56, Anthony Baker wrote:
>> On Aug 17, 2017, at 1:41 PM, Dan Smith <ds...@pivotal.io> wrote:
>>
>> Which means
>> the develop needs a way override the permission level *before* the function
>> executes.
> I agree. Providing a callback to allow a user to override the default security level seems reasonable.
>
> Anthony
>
>
Re: [DISCUSS] authorizing function execution
Posted by Anthony Baker <ab...@pivotal.io>.
> On Aug 17, 2017, at 1:41 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> Which means
> the develop needs a way override the permission level *before* the function
> executes.
I agree. Providing a callback to allow a user to override the default security level seems reasonable.
Anthony
Re: [DISCUSS] authorizing function execution
Posted by Dan Smith <ds...@pivotal.io>.
On Thu, Aug 17, 2017 at 12:10 PM, Swapnil Bawaskar <sb...@pivotal.io>
wrote:
> So, it sounds like if we did #1 above: i.e:
> 1) externalize SecurityService so that function author can use it in the
> function.execute code to check authorization.
>
> we could get this to work with lambdas:
> ResultCollector rc = getExecution().execute(context ->
> context.getCache().getSecurityService().authorizeRead();
> // perform read
> context.getResultSender().lastResult(result)
> );
>
I'm a bit confused by this proposal. The current behavior is that a
function requires write. Are you saying that we will change that so that
anyone can execute a function, and then all functions need to call this
method to check for what authorization level they want? I think we should
keep the current behavior of requiring write access by default. Which means
the develop needs a way override the permission level *before* the function
executes.
You could technically make marker interfaces work with lambdas, or if we
provide annotations, users can create their own marker interfaces.
execute((ReadOnlyFunction) context -> ....)
-Dan
Re: [DISCUSS] authorizing function execution
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
So, it sounds like if we did #1 above: i.e:
1) externalize SecurityService so that function author can use it in the
function.execute code to check authorization.
we could get this to work with lambdas:
ResultCollector rc = getExecution().execute(context ->
context.getCache().getSecurityService().authorizeRead();
// perform read
context.getResultSender().lastResult(result)
);
Udo,
I think there are plenty of use cases where a user would only have
privileges to read data, if this reading of data involves a function, that
user will need write privileges too.
On Thu, Aug 17, 2017 at 11:26 AM Udo Kohlmeyer <uk...@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 <uk...@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("functionExecutor"))*/
> >> 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 <
> mdodge@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 <sb...@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.
> >>>>>
> >>>>
>
>
Re: [DISCUSS] authorizing function execution
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
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 <uk...@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("functionExecutor"))*/
>> 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 <mdodge@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 <sb...@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.
>>>>>
>>>>
Re: [DISCUSS] authorizing function execution
Posted by Dan Smith <ds...@pivotal.io>.
> 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 <uk...@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("functionExecutor"))*/
> 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 <mdodge@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 <sb...@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.
>>>>
>>>
>>>
>
Re: [DISCUSS] authorizing function execution
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
I think there might be more to this than just "Data:READ"/"Data:WRITE".
Why would we not support something like
/*@Authorize(hasRole("functionExecutor"))*/ 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 <md...@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 <sb...@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.
>>
Re: [DISCUSS] authorizing function execution
Posted by Dan Smith <ds...@pivotal.io>.
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 <md...@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 <sb...@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.
>
>
Re: [DISCUSS] authorizing function execution
Posted by Michael William Dodge <md...@pivotal.io>.
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 <sb...@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.
Re: [DISCUSS] authorizing function execution
Posted by Michael Stolz <ms...@pivotal.io>.
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 <sb...@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 <ag...@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 <js...@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 <agingade@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 <jstewart@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 <
> sbawaskar@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.
> > > >>
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] authorizing function execution
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
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 <ag...@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 <js...@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 <ag...@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 <js...@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 <sb...@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.
> > >>
> > >>
> >
> >
>
Re: [DISCUSS] authorizing function execution
Posted by Anilkumar Gingade <ag...@pivotal.io>.
>> 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 <js...@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 <ag...@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 <js...@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 <sb...@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.
> >>
> >>
>
>
Re: [DISCUSS] authorizing function execution
Posted by Jared Stewart <js...@pivotal.io>.
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 <ag...@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 <js...@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 <sb...@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.
>>
>>
Re: [DISCUSS] authorizing function execution
Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <js...@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 <sb...@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.
>
>
Re: [DISCUSS] authorizing function execution
Posted by Jared Stewart <js...@pivotal.io>.
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 <sb...@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.