[
https://issues.apache.org/jira/browse/CASSANDRA-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-9481.
---------------------------------------
Resolution: Won't Fix
Largely unnecessary with the successful resolution of 9402.
> FENCED UDFs
> -----------
>
> Key: CASSANDRA-9481
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9481
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Brian Hess
>
> Related to security/sandboxing of UDFs (CASSANDRA-9042)
> Essentially, the UDF will run in a separate process when it is registered as
> FENCED, and run in-process when it is registered as UNFENCED.
> This doesn't necessarily remove all the issues, but it does help mitigate
> them/some - especially since it would (optionally) run as another user.
> This could look like the following with Cassandra:
> - FENCED is a GRANTable privilege
> - In cassandra.yaml you can specify the user to use when launching the
> separate process (so that it is not the same user that is running the
> database - or optionally is)
> - This is good so that the UDF can't stop the database, delete database
> files, etc.
> - For FENCED UDFs, IPC would be used to transfer rows to the UDF and to
> return results. We could use CQL rows for the data. This could be shared
> memory or sockets (Unux or TPC - slight preference for sockets for some
> follow-on ideas).
> - Ideally, switching from FENCED to UNFENCED would be just a DDL change. That
> is, the API would work such that a simple "ALTER FUNCTION myFunction(DOUBLE,
> DOUBLE) UNFENCED" would change it.
> - If you wanted, because this is a separate process you could use a separate
> class loader.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
