Security Practices for UDFs and Procedures¶

Practices for UDF Handlers¶

Your function or method (and any library functions or methods that you call) must act as a pure function, acting only on the data it receives and returning a value based on that data, without causing side-effects. Your code should not attempt to affect the state of the underlying system, other than consuming a reasonable amount of memory and processor time.

Practices for Procedure and UDF Handlers¶

Handler code executes within a restricted engine. Neither your code nor the code in library methods that you use should employ any prohibited system calls, including:

• Process control. For example, you cannot fork a process. (However, you can use multiple threads.)

• Access to the file system on which the handler is running.

  With the following exceptions, a handler should not read or write files:

  • A handler can read staged files specified in the IMPORTS clause. For more information, see CREATE FUNCTION or CREATE PROCEDURE.

  • A handler can write files, such as log files, to the /tmp directory.

    Each query gets its own memory-backed file system in which its own /tmp is stored, so different queries cannot have file name conflicts.

    However, conflicts within a query are possible if a single query calls more than one UDF, and those UDFs try to write to the same file name.

    Note

    Also, because Python UDFs may execute in separate worker processes in parallel, you should be careful about writing into the /tmp directory.

    For more on writing files, see Writing Files. For an example, see Unzipping a Staged File.

• Network access.

  You can’t use a handler to create sockets, but you can use a handler to access resources on an external network.

  Note

  You cannot use the code in the Snowflake JDBC Driver to access the database. Your UDF cannot itself act as a client of Snowflake.