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