DBSECADM Clause

The GRANT DBSECADM statement enables the user to whom the DBSECADM role is granted to issue DDL statements that can create, alter, rename, or drop security objects, including security policies, security labels, and security components.

DBSECADM Clause

1   DBSECADM TO + ,?  USER user

Element Description Restrictions Syntax
user User to whom the role is to be granted Must be the authorization identifier of a user Owner name

The DBSECADM role is a built-in role that only the DBSA can grant. Unlike user-defined roles, whose scope is the database in which the role is created, the scope of the DBSECADM role is all of the databases of the HCL OneDB™ instance. It is not necessary for DBSA to reissue the GRANT DBSECADM statement in other databases of the same server. Like all built-in roles of HCL OneDB, the DBSECADM role is enabled when it is granted, without requiring activation by the SET ROLE statement, and it remains in effect until it is revoked.

Only a user who holds the DBSECADM role can issue the following SQL statements that create or modify security objects:
  • ALTER SECURITY LABEL COMPONENT
  • CREATE SECURITY LABEL
  • CREATE SECURITY LABEL COMPONENT
  • CREATE SECURITY POLICY
  • DROP SECURITY LABEL
  • DROP SECURITY LABEL COMPONENT
  • DROP SECURITY POLICY
  • RENAME SECURITY LABEL
  • RENAME SECURITY LABEL COMPONENT
  • RENAME SECURITY POLICY
Only a user who holds the DBSECADM role can use the following SQL statements to reference tables that are protected by a security policy:
  • ALTER TABLE ... ADD SECURITY POLICY
  • ALTER TABLE ... ADD ... IDSSECURITYLABEL [DEFAULT label]
  • ALTER TABLE ... ADD ... [COLUMN] SECURED WITH
  • ALTER TABLE ... DROP SECURITY POLICY
  • ALTER TABLE ... MODIFY ... [COLUMN] SECURED WITH
  • ALTER TABLE ... MODIFY ... DROP COLUMN SECURITY
  • CREATE TABLE ... COLUMN SECURED WITH
  • CREATE TABLE ... IDSSECURITYLABEL [DEFAULT label]
  • CREATE TABLE ... SECURITY POLICY
The following GRANT and REVOKE statements also cannot be issued by a user who does not hold the DBSECADM role:
  • GRANT EXEMPTION
  • GRANT SECURITY LABEL
  • GRANT SETSESSIONAUTH
  • REVOKE EXEMPTION
  • REVOKE SECURITY LABEL
  • REVOKE SETSESSIONAUTH

The USER keyword that can follow the TO keyword is optional, and has no effect, but any authorization identifier that the DBSA specifies in the GRANT DBSECADM statement must be the identifier of an individual user, rather than the identifier of a role, or the PUBLIC group.

The user can be the DBSA who issues this GRANT DBSECADM statement. This is an important exception to the general restriction that the TO clause of the GRANT statement (like the FROM clause in the REVOKE statements) cannot explicitly reference the authorization identifier of the user who issues the statement. Unlike other roles, access privileges, user security labels, and exemptions on rules that the GRANT statement can specify, you can grant the DBSECADM role to yourself, if you are user informix, or a member of the DBSA group, or (on Windows™ if you are a member of the Informix-Admin group.

In the following example, the DBSA grants the DBSECADM role to user niccolo: 
GRANT DBSECADM TO niccolo;
If this statement executes successfully, user niccolo can perform the LBAC operations listed above, provided that niccolo also holds sufficient discretionary access privileges on the database and on the database objects that those SQL statements reference.

After a user is granted the DBSECADM role, only the DBSA can revoke it.

For a discussion of LBAC security objects, see your HCL OneDB Security Guide.