cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7557) User permissions for UDFs
Date Fri, 10 Apr 2015 21:38:12 GMT


Tyler Hobbs commented on CASSANDRA-7557:

bq.  I've taken the lead from DROP TABLE - when IF EXISTS is used the statement silently succeeds,
bypassing authz. When IF EXISTS is not present, we throw an IRE with "Unconfigured function
ks.func(args)". wdyt?

That seems reasonable to me.

After looking over the tests again, I've come up with a few more things that would be good
to test (apologies if any of these are already covered and I missed them):
* Granting both root/ks-level permissions _and_ individual function permissions, ensuring
that revoking one does not affect revoking the other
* Similar to {{drop_function_and_keyspace_cleans_up_udf_permissions_test}}, test that dropping
a keyspace drops function-level permissions for functions in that keyspace
* Ensure granting permissions on a builtin function (e.g. {{}}) errors nicely. 
Same for REVOKE on builtins and granting EXECUTE on non-function objects.
* Double granting/revoking is well-behaved (I'm not sure if it's supposed to error or succeed)

Also, in the {{inheritance_of_udf_permissions_test}}, shouldn't the {{GRANT EXECUTE}} statement
be executed by the {{function_user}} role instead of {{cassandra}}?

> User permissions for UDFs
> -------------------------
>                 Key: CASSANDRA-7557
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Sam Tunnicliffe
>              Labels: client-impacting, cql, udf
>             Fix For: 3.0
> We probably want some new permissions for user defined functions.  Most RDBMSes split
function permissions roughly into {{EXECUTE}} and {{CREATE}}/{{ALTER}}/{{DROP}} permissions.

This message was sent by Atlassian JIRA

View raw message