[ https://issues.apache.org/jira/browse/CASSANDRA-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651786#comment-14651786 ]
Robert Stupp commented on CASSANDRA-9892: ----------------------------------------- Summary what's been discussed on IRC: * don't rush (it's a public API and security related) - there's still some time until beta/rc1 * agreed on the term _trusted_ for non-sandboxed UDFs (_untrusted_ as a permission/resource would be confusing in combination with _create untrusted function_") * agreed (preliminary) on _GRANT CREATE TRUSTED FUNCTION_ resp. _GRANT EXECUTE TRUSTED FUNCTION_ and _CREATE TRUSTED FUNCTION_ * the only (technical) issue i see with "TRUSTED FUNCTION" as an extension to FunctionResource is granting/revoking (grant "create trusted function" when role already has "create function", etc). but that could be avoided with a new TrustedFunctionResource or some coding. > Add support for unsandboxed UDF > ------------------------------- > > Key: CASSANDRA-9892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9892 > Project: Cassandra > Issue Type: New Feature > Reporter: Jonathan Ellis > Assignee: Robert Stupp > Priority: Minor > > From discussion on CASSANDRA-9402, > The approach postgresql takes is to distinguish between "trusted" (sandboxed) > and "untrusted" (anything goes) UDF languages. > Creating an untrusted language always requires superuser mode. Once that is > done, creating functions in it requires nothing special. > Personally I would be fine with this approach, but I think it would be more > useful to have the extra permission on creating the function, and also > wouldn't require adding explicit CREATE LANGUAGE. > So I'd suggest just providing different CQL permissions for trusted and > untrusted, i.e. if you have CREATE FUNCTION permission that allows you to > create sandboxed UDF, but you can only create unsandboxed if you have CREATE > UNTRUSTED. -- This message was sent by Atlassian JIRA (v6.3.4#6332)