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 <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("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 <
> 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.
> >>>>>
> >>>>
>
>
