Details

    • Type: New Feature
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Fix Version/s: 4.x
    • Component/s: None
    • Labels:

      Description

      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.

        Issue Links

          Activity

          Hide
          snazy Robert Stupp added a comment -

          I agree, having this using a syntax extension to CREATE FUNCTION is much nicer.

          I'm a bit confused with the wording (un)trusted
          Shouldn't it be CREATE TRUSTED instead of UNTRUSTED to bypass the sandbox and CREATE TRUSTED FUNCTION?
          If I trust a function, it can execute without being sandboxed.

          When having this, I would remove the (then) superfluous, undocumented config option enable_user_defined_functions_threads.

          Show
          snazy Robert Stupp added a comment - I agree, having this using a syntax extension to CREATE FUNCTION is much nicer. I'm a bit confused with the wording (un)trusted Shouldn't it be CREATE TRUSTED instead of UNTRUSTED to bypass the sandbox and CREATE TRUSTED FUNCTION? If I trust a function, it can execute without being sandboxed. When having this, I would remove the (then) superfluous, undocumented config option enable_user_defined_functions_threads .
          Hide
          jbellis Jonathan Ellis added a comment -

          I get what you mean, but from a user's perspective it would mean we "trust" the server to guarantee that the function can't do bad things.

          We could use a different term if that's confusing though.

          Show
          jbellis Jonathan Ellis added a comment - I get what you mean, but from a user's perspective it would mean we "trust" the server to guarantee that the function can't do bad things. We could use a different term if that's confusing though.
          Hide
          snazy Robert Stupp added a comment -

          CREATE [ [ NON ] SANDBOXED ] FUNCTION ?

          Show
          snazy Robert Stupp added a comment - CREATE [ [ NON ] SANDBOXED ] FUNCTION ?
          Hide
          brianmhess Brian Hess added a comment -

          I don't particularly like the change of the meaning of FENCED/UNFENCED, but we could use that. FENCED being safe and UNFENCED being unsafe. This is what DB2 and Netezza do.

          Show
          brianmhess Brian Hess added a comment - I don't particularly like the change of the meaning of FENCED/UNFENCED, but we could use that. FENCED being safe and UNFENCED being unsafe. This is what DB2 and Netezza do.
          Hide
          snazy Robert Stupp added a comment -

          Implemented support for UNTRUSTED UDFs in this branch. UNTRUSTED permission is required to create such UDFs.

          Wrt nomenclature, after some days, I'm now fine with UNTRUSTED.

          UNTRUSTED means:

          • It's up to you, dear user, to ensure that the code does not do anything bad!
          • C* cannot do anything for you, dear user, to trust the code.
          • No sandbox.
          • No security manager.
          • No async execution.

          Cassci is happy (no regression, latest push as of today is just cosmetic stuff):
          testall
          dtest

          Show
          snazy Robert Stupp added a comment - Implemented support for UNTRUSTED UDFs in this branch . UNTRUSTED permission is required to create such UDFs. Wrt nomenclature, after some days, I'm now fine with UNTRUSTED. UNTRUSTED means: It's up to you, dear user, to ensure that the code does not do anything bad! C* cannot do anything for you, dear user, to trust the code. No sandbox. No security manager. No async execution. Cassci is happy (no regression, latest push as of today is just cosmetic stuff): testall dtest
          Hide
          tjake T Jake Luciani added a comment -

          Isn't that backwards? Wouldn't TRUSTED mean you don't apply any safeguards because you trust the method? vs UNTRUSTED you safeguard?

          Show
          tjake T Jake Luciani added a comment - Isn't that backwards? Wouldn't TRUSTED mean you don't apply any safeguards because you trust the method? vs UNTRUSTED you safeguard?
          Hide
          brianmhess Brian Hess added a comment -

          Yeah - I agree with T Jake Luciani and Robert Stupp. TRUSTED should mean that the function can be run without the extra safeguards. You trust the function.

          Show
          brianmhess Brian Hess added a comment - Yeah - I agree with T Jake Luciani and Robert Stupp . TRUSTED should mean that the function can be run without the extra safeguards. You trust the function.
          Hide
          snazy Robert Stupp added a comment -

          (un)trusted seems to be confusing. How about Brian Hess' proposal UNFENCED?

          Show
          snazy Robert Stupp added a comment - (un)trusted seems to be confusing. How about Brian Hess ' proposal UNFENCED?
          Hide
          snazy Robert Stupp added a comment -

          Git branch uses TRUSTED

          Show
          snazy Robert Stupp added a comment - Git branch uses TRUSTED
          Hide
          iamaleksey Aleksey Yeschenko added a comment -

          /cc Sam Tunnicliffe

          Haven't looked at the patch in detail, yet, but TRUSTED is not a proper name for a permission.

          Show
          iamaleksey Aleksey Yeschenko added a comment - /cc Sam Tunnicliffe Haven't looked at the patch in detail, yet, but TRUSTED is not a proper name for a permission.
          Hide
          snazy Robert Stupp added a comment -

          Yea - we need a good name for this. Current proposals are:
          UNTRUSTED, TRUSTED, UNFENCED, NON_SANDBOXED

          I like TRUSTED (the user trusts) or UNFENCED (no fence around the function).

          Show
          snazy Robert Stupp added a comment - Yea - we need a good name for this. Current proposals are: UNTRUSTED, TRUSTED, UNFENCED, NON_SANDBOXED I like TRUSTED ( the user trusts ) or UNFENCED ( no fence around the function ).
          Hide
          beobal Sam Tunnicliffe added a comment -

          The problem with TRUSTED (and also any of the suggestions above) is that it doesn't describe an action (or set of actions) which the permission allows. Existing permissions are all verbs, which shows this nicely. I also haven't looked at the patch in detail yet, but off the top of my head something like CREATE_TRUSTED is the best I can come up with (and to be clear that I don't like that very much either).

          Show
          beobal Sam Tunnicliffe added a comment - The problem with TRUSTED (and also any of the suggestions above) is that it doesn't describe an action (or set of actions) which the permission allows. Existing permissions are all verbs, which shows this nicely. I also haven't looked at the patch in detail yet, but off the top of my head something like CREATE_TRUSTED is the best I can come up with (and to be clear that I don't like that very much either).
          Hide
          snazy Robert Stupp added a comment -

          GRANT CREATE TRUSTED FUNCTION TO ... could be the privilege to create non-sandboxed functions. But it would require some extension to the authz code + schema.

          GRANT CREATE TRUSTED TO ... could be an additional privilege required to create non-sandboxed functions (in addition to CREATE FUNCTION privilege).

          GRANT TRUST FUNCTION TO ... would be a new permission (thus requiring CREATE + TRUST permissions).

          Show
          snazy Robert Stupp added a comment - GRANT CREATE TRUSTED FUNCTION TO ... could be the privilege to create non-sandboxed functions. But it would require some extension to the authz code + schema. GRANT CREATE TRUSTED TO ... could be an additional privilege required to create non-sandboxed functions (in addition to CREATE FUNCTION privilege). GRANT TRUST FUNCTION TO ... would be a new permission (thus requiring CREATE + TRUST permissions).
          Hide
          beobal Sam Tunnicliffe added a comment -

          I wasn't referring to the proposed syntax, but the name of the new element in the o.a.c.auth.Permission enum.

          That said, what would the intention of GRANT TRUST FUNCTION TO ... be? It reads like it should give a role the ability to turn an untrusted function into a trusted one. I don't see anything in JIRA about adding the ability to change that post-hoc.

          Show
          beobal Sam Tunnicliffe added a comment - I wasn't referring to the proposed syntax, but the name of the new element in the o.a.c.auth.Permission enum. That said, what would the intention of GRANT TRUST FUNCTION TO ... be? It reads like it should give a role the ability to turn an untrusted function into a trusted one. I don't see anything in JIRA about adding the ability to change that post-hoc.
          Hide
          snazy Robert Stupp added a comment -

          Hm - it's not intended to change the trusted status post-hoc. The intention is to require CREATE FUNCTION and TRUST FUNCTION privileges on collection level to create a non-sandboxed function.

          Show
          snazy Robert Stupp added a comment - Hm - it's not intended to change the trusted status post-hoc. The intention is to require CREATE FUNCTION and TRUST FUNCTION privileges on collection level to create a non-sandboxed function.
          Hide
          beobal Sam Tunnicliffe added a comment -

          Ok, so those are 3 options/suggestions for the same thing (the syntax to enable a role to create untrusted functions)? I would still say that the last one reads as something related to changing the status of an existing function because it doesn't refer to creation. Of the first 2 suggestions, I'd choose the more explicit GRANT CREATE TRUSTED FUNCTION TO ..., the earlier comment about the Permission name itself (aside from the CQL syntax) still stands though - TRUSTED is incongruous with the existing permissions.

          Show
          beobal Sam Tunnicliffe added a comment - Ok, so those are 3 options/suggestions for the same thing (the syntax to enable a role to create untrusted functions)? I would still say that the last one reads as something related to changing the status of an existing function because it doesn't refer to creation. Of the first 2 suggestions, I'd choose the more explicit GRANT CREATE TRUSTED FUNCTION TO ... , the earlier comment about the Permission name itself (aside from the CQL syntax) still stands though - TRUSTED is incongruous with the existing permissions.
          Hide
          iamaleksey Aleksey Yeschenko added a comment -

          There is also EXECUTE UNTRUSTED FUNCTION. So I guess a new resource (or some flexibility to FunctionResource) is what we need, not new permissions.

          Show
          iamaleksey Aleksey Yeschenko added a comment - There is also EXECUTE UNTRUSTED FUNCTION . So I guess a new resource (or some flexibility to FunctionResource ) is what we need, not new permissions.
          Hide
          snazy Robert Stupp added a comment -

          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.
          Show
          snazy Robert Stupp added a comment - 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.
          Hide
          jbellis Jonathan Ellis added a comment -

          Let's push this to 3.2 rather than feature creeping 3.0.

          Show
          jbellis Jonathan Ellis added a comment - Let's push this to 3.2 rather than feature creeping 3.0.
          Hide
          michaelsembwever mck added a comment -

          Bumping to fix version 4.x, as 3.11.0 is a bug-fix only release.
            ref https://s.apache.org/EHBy

          Show
          michaelsembwever mck added a comment - Bumping to fix version 4.x, as 3.11.0 is a bug-fix only release.   ref https://s.apache.org/EHBy

            People

            • Assignee:
              snazy Robert Stupp
              Reporter:
              jbellis Jonathan Ellis
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development