15.00 - Authorization Rules - Teradata Database

Teradata Database SQL Data Definition Language Detailed Topics

prodname
Teradata Database
vrm_release
15.00
category
Programming Reference
featnum
B035-1184-015K

Authorization Rules

  • When you submit a CREATE AUTHORIZATION request, Teradata 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 EXERNAL 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 is using Kerberos to do authentication, then the specified user is 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 (see “CREATE MACRO/ REPLACE MACRO” on page 394) because the authorization password is not saved in either encrypted or unencrypted form. This is because doing so would compromise the security of the OS logon user ID.
  • Any external routine that is designed to access external data must run in either secure or protected mode as a separate process under the user ID of an OS platform user. There are several reasons for doing this, primarily because the OS I/O calls need a context for accessing data and determining which data it has access to. The only way to do this is to run the external routine as a separate process under the authorization of a specific OS 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 Teradata Database.

    The tdatudf group must always exist and must never be altered.

    The reason for these restrictions is that Teradata 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 (see Utilities: Volume 1 (A-K)).
  • When modifying the cufconfig fields, keep in mind 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, then 4 megabytes of system disk file space are required, as indicated by the following equation.

    By substitution, for a system defined with 2 protected mode servers per vproc, 4 MB of disk swap space are required.

    For a system defined with 20 protected mode servers per vproc for C and C++ external routines, 40 MB of disk swap space are required.

    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.

    If, however, the 10 sessions execute the UDF queries sequentially, then only one protected mode process per vproc needs to 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.