[
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)
