SYSCTRL administrative authority

The SYSCTRL authority is designed for administering a system that contains sensitive data. With the SYSCTRL authority, you have nearly complete control of the Db2 subsystem. However, you cannot access user data directly unless you are explicitly granted the privileges to do so.

Begin general-use programming interface information. Regardless of the SEPARATE_SECURITY setting, an authorization ID or role with the SYSCTRL authority can perform the following actions:

Act as installation SYSOPR (when the catalog is available) or DBCTRL over any database
Run any allowable utility on any database
Issue a COMMENT ON, LABEL ON, or LOCK TABLE statement for any table
Create a view on any catalog table for itself or for other IDs
Create tables and aliases for itself or for others IDs
Bind a new plan or package and name any ID as the owner of the plan or package
Create roles (only if SEPARATE_SECURITY is set to NO)
Use any valid value for OWNER in BIND or REBIND (only if SEPARATE_SECURITY is set to NO)
Has implicit ACCESSCTRL authority to grant most privileges (only if SEPARATE_SECURITY is set to NO)

However, you cannot perform the following actions without the required additional privileges:

Execute SQL statements that change data in any user tables or views
Run plans or packages
Set the current SQL ID to a value that is not one of its primary or secondary IDs
Start or stop the database that contains the application registration table (ART) and the object registration table (ORT)
Act fully as SYSADM or as DBADM over any database
Access Db2 when the subsystem is started with ACCESS(MAINT)

The SYSCTRL authority is intended to separate system control functions from administrative functions. However, SYSCTRL is not a complete solution for a high-security system. If any plans have their EXECUTE privilege granted to PUBLIC, an ID or role with the SYSCTRL authority can grant itself the SYSADM authority. The only control over such actions is to audit the activity of IDs with high levels of authority.

When SEPARATE_SECURITY is set to NO, users with SYSADM authority can manage most security objects, perform grants, and revoke privileges that are granted by others, and users with SYSCTRL authority can manage roles, perform most grants, and revoke privileges that are granted by others.

Start of change However, the following newer security capabilities always require explicit SECADM authority, even if SEPARATE_SECURITY is set to NO: End of change

The following tables summarizes any included authorities, and privileges held and grantable to others, by the SYSCTRL administrative authority.

Table 1. Included authorities and grantable privileges for SYSCTRL authority
Included authorities	Installation SYSOPR (except for accessing Db2 when the subsystem is started with ACCESS(MAINT), or issuing the ACTIVATE command or running the CATMAINT utility), SYSOPR, ACCESSCTRL (except the ability to grant certain authorities, such as SYSADM, DBADM, PACKADM, and certain privileges, such as DELETE, INSERT, SELECT, and UPDATE on user tables or views, EXECUTE on plans, packages, functions, or stored procedures, PACKADM on collections, and USAGE on distinct types, JARs, and sequences) DBCTRL, DBMAINT,
Additional grantable privileges	System privileges: BINDADD BINDAGENT BSDS CREATEALIAS CREATEDBA CREATEDBC CREATESG CREATETMTAB MONITOR1 MONITOR2 STOSPACE Privileges on all tables: ALTER INDEX REFERENCES TRIGGER Privileges on all catalog tables: SELECT Privileges on updatable catalog tables (except SYSIBM.SYSAUDITPOLICIES): DELETE INSERT UPDATE Privileges on all plans: BIND Privileges on all packages: BIND COPY Privileges on all collections: CREATEIN Privileges on all schemas: ALTERIN CREATEIN DROPIN Privileges on use: BUFFERPOOLS STOGROUP TABLESPACE

End general-use programming interface information.