You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by " Brian Hess (JIRA)" <ji...@apache.org> on 2015/05/26 19:14:17 UTC

[jira] [Created] (CASSANDRA-9481) FENCED UDFs

 Brian Hess created CASSANDRA-9481:
--------------------------------------

             Summary: 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)