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