- When you submit a CREATE AUTHORIZATION request, the database validates the authorization. The system verifies the following items, and if any of them is false, the authorization attempt returns an error:
- The OS password is validated on each node.
- The OS platform user must belong to the OS group named tdatudf.
tdatudf need not be the primary group for the OS platform user, but that user must be a member of the group. Consult your Linux operating system documentation, as appropriate, for the specific definitions of group, local group, and so on.
The tdatudf group is used by protected mode external routines and must always exist. You can change the tdatudf group assignment for external routines using their EXTERNAL SECURITY clause.
The best practice is to make this group serve only the external routines that specify an EXTERNAL SECURITY clause and not use it for any other purpose.
- The authentication process uses whichever authentication methods are set up by your site. For example, if your site uses Kerberos for authentication, then users are validated using that method.
Authentication is automatic as long as the platform nodes are part of the global authentication process. If they are not part of that process, then you must create a local OS user on each node. A local OS user is any user that must be created manually. Local OS users are not associated with a domain.
- You cannot specify CREATE AUTHORIZATION in a macro definition because the authorization password is not saved in either encrypted or unencrypted form. This would compromise the security of the OS logon user ID. See CREATE MACRO and REPLACE MACRO.
- Any external routine that accesses external data must run in either secure or protected mode as a separate process under the user ID of an OS platform user.
When you create an external routine that includes an EXTERNAL SECURITY clause, the name of the OS user specified in that clause must be a member of the group tdatudf. The system creates this group by default during the installation of the database.
The tdatudf group must always exist and must not be altered.
The reason for these restrictions is that the database always uses the tdatudf group to run protected or secure mode routines.
When an external routine runs in either protected or secure mode, it runs as the OS user associated with its authorization.
In both protected and secure modes, the system sets the platform process up on a PE or AMP vproc as needed to execute the external routine.
You can run a maximum of 20 protected mode servers and 20 secure mode servers per AMP or PE. To clarify, you can run up to 40 “protected” mode servers concurrently per AMP or PE, but not more than 20 each of the protected and secure mode types.
- The number of server processes that can be set up on any one vproc is limited. The limit for both C/C++ and Java servers is controlled by different fields of the cufconfig utility. For more information, see Teradata Vantage™ - Database Utilities, B035-1102.
When modifying the cufconfig fields, note that each protected or secure mode process uses its own private shared memory, which requires private disk swap space. Each process for a routine written in C or C++ requires 256 KB of disk space.
For example, if two protected mode servers are allocated per vproc and there are 8 vprocs on the node, 4 megabytes of system disk file space is required. Refer to the following equation.
By substitution, a system defined with 2 protected mode servers per vproc requires 4 MB of disk swap space.
A system defined with 20 protected mode servers per vproc for C and C++ external routines requires 40 MB of disk swap space.
The system does not allocate space until an external routine is executing that requires the space. If you run 10 sessions, and each one executes a query that uses a UDF at the same instance, then the system creates 10 protected mode servers per vproc.
However, if the 10 sessions execute the UDF queries sequentially, only one protected mode process per vproc must be created. Once a protected mode server is set up, it remains in existence until the database restarts. If any servers are not used, the system swaps them out to disk, so they do not consume any physical memory resources.
Each Java server for external routines requires roughly 30 MB of memory for swap space, and there can be two such Java servers per node. A Java UDF multithreaded server for non-secure mode Java UDFs uses a minimum of an additional 30 MB (the amount required can be larger, depending on the size of the JARs for a user), so each node requires approximately 100 MB of swap space if all server flavors are used.