This chapter contains the following topics:
This section contains the following topics:
GRANT Administration Privilege
GRANT System Definition Privileges
REVOKE Administration Privilege
REVOKE System Definition Privileges
Modifies the definition of an activity or a category in the system dictionary.
To modify a system, activity, or category definition, you must hold one of these privileges:
►►─── ALTER RESOURCE ─────────────────────────────────────────────────────────► ►─┬─ ACTIVITY application-name.activity-name NUMBER activity-number ─┬───────►◄ │ ┌─────────────────────────────────┐ │ └─ CATEGORY category-name ─▼─┬─ ADD ──┬─ category-component ─┴─────┘ └─ DROP ─┘
Expansion of Category-Component
┌─────────────────────── , ────────────────────────┐ ►►─┬─ ACCESS MODULE ─▼─ dictionary-name.schema-name.access-module-name ─┴─┬───►◄ │ ┌─────────────────── , ────────────────────┐ │ ├─ LOAD MODULE ─▼─ dictionary-name.Vnnnn.load-module-name ─┴───────────┤ │ ┌───────────── , ──────────┐ │ ├─ PROGRAM ─▼─ file-name.program-name ─┴───────────────────────────────┤ │ ┌────── , ─────┐ │ ├─ QUEUE ─▼─ queue-name ─┴─────────────────────────────────────────────┤ │ ┌───────────────────── , ─────────────────────┐ │ ├─ RUNUNIT ──▼─ database-name.subschema-name.program-name ─┴───────────┤ │ ┌───── , ─────┐ │ └─ TASK ─▼─ task-code ─┴───────────────────────────────────────────────┘
Specifies that you are modifying the security definition of an activity.
Identifies the application that includes the activity to be altered.
Identifies the application activity to be altered.
The activity must have been previously defined with a CREATE RESOURCE statement.
Specifies the security classification number to be assigned to the activity.
Activity-number must be in the range 1 to 256 and must be unique for the application.
Specifies that you are modifying the definition of a category.
Category-name must have been previously defined with a CREATE RESOURCE statement.
Specifies that you are adding a component to the category.
Specifies that you are dropping a component from the category.
Identifies the component to be added to or dropped from the category.
Expanded syntax for category-component directly follows syntax for ALTER RESOURCE.
A component that has been assigned to a category cannot be assigned to a second category.
You can wildcard the name of the category component.
Note: For more information about wildcarding, see Using a Wildcard.
Specifies that the category component is an access module.
If you drop an access module from a category, users with execution privilege on the category may no longer be able to execute the access module.
Identifies the dictionary where the access module is stored (DDLCATLOD area).
Identifies the schema with which the access module is associated.
Identifies the access module.
Specifies that the category component is a load module.
If you drop a load module from a category, users with execution privilege on the category may no longer be able to execute the load module.
Identifies the dictionary where the load module is stored (DDLDCLOD area).
Specifies the version of the load module.
Nnnn identifies the version number of the load module. Leading zeros must be included.
Identifies the load module.
Load-module-name must match the name of an entity defined in the dictionary by means of a CA IDMS or CA ADS compiler.
Specifies that the category component is a program.
If you drop a program from a category, users with execution privilege on the category may no longer be able to execute the program.
Supplies the external file name of the load library where the program is stored.
File-name is either 'CDMSLIB' or 'Vnnnn' where nnnn identifies the version number (2 - 9999) of the program. Nnnn must include leading zeroes.
Identifies the program.
Specifies that the category component is a queue.
If you drop a queue from a category, users with execution privilege on the category may no longer be able to create or access the queue.
Identifies the queue.
Specifies that the category component is a run unit.
If you drop a run unit from a category, users with execution privilege on the category may no longer be able to execute the run unit.
Specifies the database to be accessed by the run unit.
Specifies the subschema to be used by the run unit.
Specifies the name of the program binding the run unit.
Specifies that the category component is a task.
If you drop a task from a category, users with execution privilege on the category may no longer be able to execute the task.
Identifies the task.
Execution Privilege on Individual Access Modules
You can give access module execution privilege by issuing a GRANT EXECUTE ON ACCESS MODULE statement. However, if you subsequently add the same access module to a category, the separate grant of access module execution is ignored at runtime.
If you then drop the access module from the category, and you have not revoked the separate grant of access module execution privilege, the privilege will again be respected at runtime.
Matching Wildcarded Category Component Names
If you use a wildcard when you specify a category component name, the category to which the resource is assigned is the one that most closely matches the resource name.
A match is determined by these rules:
For example, assume you add these two category component definitions:
alter resource category hr_prod add load module hrdict.v0001*; alter resource category hr_test add load module hrdict.*;
A load module named HRDICT.V0001.HRMAP1 will be assigned to category HR_PROD, whereas load module HRDICT.V0002.HRMAP1 will be assigned to category HR_TEST.
Altering Categories After a Grant
If a component is added to a category with ALTER RESOURCE after a grant of privilege on the category, the privilege is implicitly granted on the added component. Similarly, if a component is dropped from a category with ALTER RESOURCE after a grant of privilege on the category, the privilege on the dropped component is implicitly revoked.
Altering an Activity: The following statement assigns a new number to an
existing activity created for a General Ledger application:
alter resource activity cgl.post number 5;
Altering a Category: The following statement replaces a resource in an
existing category created for a General Ledger application:
alter resource category glappl drop queue fl* add queue gl*;
For more information about creating and dropping resources, see the topics CREATE RESOURCE and DROP RESOURCE.
Creates the definition of a system, activity, or category in the system dictionary.
To create a system, activity, or category definition, you must hold one of these privileges:
►►─── CREATE RESOURCE ────────────────────────────────────────────────────────► ►─┬─ ACTIVITY application-name.activity-name NUMBER activity-number ─┬───────►◄ │ ┌──────────────────────────┐ │ ├─ CATEGORY category-name ─▼─ ADD category-component ─┴────────────┤ │ │ └─ SYSTEM system-identifier ───────────────────────────────────────┘
Expansion of Category-Component
┌─────────────────────── , ────────────────────────┐ ►►─┬─ ACCESS MODULE ─▼─ dictionary-name.schema-name.access-module-name ─┴─┬───►◄ │ ┌─────────────────── , ────────────────────┐ │ ├─ LOAD MODULE ─▼─ dictionary-name.Vnnnn.load-module-name ─┴───────────┤ │ ┌───────────── , ──────────┐ │ ├─ PROGRAM ─▼─ file-name.program-name ─┴───────────────────────────────┤ │ ┌────── , ─────┐ │ ├─ QUEUE ─▼─ queue-name ─┴─────────────────────────────────────────────┤ │ ┌───────────────────── , ─────────────────────┐ │ ├─ RUNUNIT ──▼─ database-name.subschema-name.program-name ─┴───────────┤ │ ┌───── , ─────┐ │ └─ TASK ─▼─ task-code ─┴───────────────────────────────────────────────┘
Specifies that you are defining an activity as a secured resource.
An activity is a discrete application function. After you have defined an activity, you grant execution privilege on the activity to users.
Note: For more information about activities, see the chapter Securing System Resources.
Identifies the application that includes the activity to be secured.
Application-name must match the name of the application (passed in #SECHECK) whose function is being secured. It can be at most eight characters in length.
Names the application function to be secured.
Activity-name must be unique within the application. It can be at most 18 characters in length.
Specifies the activity number assigned to the application function.
Activity-number must be unique within the application. It must be in the range 1 to 256, and it must match the security class assigned within the application.
Note: For more information about assigning activity numbers within applications, see the chapter Securing System Resources.
Specifies that you are defining category category-name as a secured resource.
A category can contain tasks, load modules, programs, access modules, run units, and queues. After you have defined a category, you grant execution privilege on the category to users.
Category-name can be at most 32 characters in length.
You can define a maximum of 32,767 categories for a DC system.
Note: For more information about categories, see the chapter Securing System Resources.
Identifies a component to be added to the category.
Expanded syntax for category-component directly follows syntax for CREATE RESOURCE.
A component that has been assigned to a category cannot be assigned to a second category.
You can wildcard the name of the category component.
Note: For more information about wildcarding, see Using a Wildcard.
Specifies that system system-identifier is a secured resource. When the system is secured, users must hold definition privileges to define the system and signon privilege to sign on to the system.
When the system is defined, SYSTEM ID in the SYSTEM statement of system generation must match the value of system-identifier.
Specifies that the category component is an access module.
After you add an access module to a category, a user with execution privilege on the category can load the access module but cannot execute it.
Identifies the dictionary where the access module is stored (DDLCATLOD area).
Identifies the schema with which the access module is associated.
Identifies an access module.
Specifies that the category component is a load module.
After you add a load module to a category, a user with execution privilege on the category can execute the load module.
Identifies the dictionary where the load module is stored (DDLDCLOD area).
Specifies the version of the load module.
Nnnn identifies the version number of the load module. Leading zeros must be included.
Identifies a load module.
Specifies that the category component is a program.
After you add a program to a category, a user with execution privilege on the category can execute the program.
Supplies the name of the external file of the load library where the program is stored.
File-name is either 'CDMSLIB' or 'Vnnnn' where nnnn identifies the version number (2 - 9999) of the program. Nnnn must include leading zeroes.
Identifies a program.
Specifies that the category component is a queue.
After you add a queue to a category, a user with execution privilege on the category can create or access the queue.
Identifies a queue.
Specifies that the category component is a run unit.
After you add a run unit to a category, a user with execution privilege on the category can use program-name to access data described in subschema-name of database-name.
Identifies the database to be accessed by the run unit.
Identifies the subschema to be used by the run unit.
Identifies the program binding the run unit.
Specifies that the category component is a task.
After you add a task to a category, a user with execution privilege on the category can execute the task.
Identifies the task.
Adding Categories or Applications After a Grant
A category created after you grant privileges on the category with a wildcard is not included in the scope of the grant even if the resource name matches the wildcarded name. The wildcard is processed at the time the grant is made, not at runtime.
For example, if you create categories X1, X2, and X3, and then grant privileges on category X*, the three categories are within the scope of the grant. If you then create category X4, this category is not within the scope of the grant.
You can include X4 within the scope of the grant by reissuing the original grant on category X*.
The same considerations apply if you wildcard activity-name when granting execution privilege on an activity. The wildcard is processed at the time the grant is made, not at runtime.
Altering Categories After a Grant
If a component is added to a category (ALTER RESOURCE) after a grant of privilege on the category, the privilege is implicitly granted on the added component. Similarly, if a component is dropped from a category (ALTER RESOURCE) after a grant of privilege on the category, the privilege on the dropped component is implicitly revoked.
Matching Wildcarded Category Component Names
If you use a wildcard when you specify a category component name, the category to which the resource is assigned is the one that most closely matches the resource name.
A match is determined by these rules:
For example, assume you add these two category component definitions:
create resource category hr_prod add load module hrdict.v0001*; create resource category hr_test add load module hrdict.*;
A load module named HRDICT.V0001.HRMAP1 will be assigned to category HR_PROD, whereas load module HRDICT.V0002.HRMAP1 will be assigned to category HR_TEST.
The following statement creates a category called PROD_ACCESS that includes resources required for a user to perform production processing:
create resource
category prod_access
add access module proddict.prod*
add load module proddict.v0001.*
add program cdmslib.*
add rununit p*;
Creating an Activity
The following statement assigns an activity name and number to a General Ledger application:
create resource activity cgl.post number 4;
Creating a Category
The following statement creates a category of resources used by a General Ledger application:
create resource
category glappl
add load module appldict.v0001.gl*
add task gl*
add queue gl*
add program cdmslib.gl*;
For more information about altering and dropping resources, see “ALTER RESOURCE” and “DROP RESOURCE.”
Deletes the definition of a secured resource.
To delete the definition of a system, activity, or category as a secured resource, you must hold one of these privileges:
►►─── DROP RESOURCE ─┬─ ACTIVITY application-name.activity-name ─┬────────────►◄ ├─ CATEGORY category-name ──────────────────┤ └─ SYSTEM system-identifier ────────────────┘
Specifies that the resource to be dropped is an activity.
Identifies the activity.
Specifies that the resource to be dropped is a category.
Identifies the category.
Specifies that the resource to be dropped is a system.
Identifies the system.
Automatic Revoking of Privileges
When you drop a resource, you implicitly revoke all privileges granted on the resource.
Dropping an Activity
The following statement drops an existing activity created for a General Ledger application:
drop resource activity cgl.post;
Dropping a Category
The following statement drops an existing category created for a General Ledger application:
drop resource category glappl;
For more information about creating and altering resources, see CREATE RESOURCE and ALTER RESOURCE.
Gives one or more users or groups DCADMIN privilege.
To grant DCADMIN privilege, you must hold one of these privileges:
►►─── GRANT DCADMIN ──────────────────────────────────────────────────────────► ┌─────────────── , ──────────────┐ ►─── TO ─▼─┬─ PUBLIC ───────────────────┬─┴──────────────────────────────────►◄ └─ authorization-identifier ─┘
Specifies that you are giving DCADMIN privilege to the users or groups identified in the TO parameter.
DCADMIN controls access to DC system resources. A user with DCADMIN privilege can define system resources and can grant and revoke privileges on system resources.
Note: For more information about the DCADMIN privilege, see Securing System Resources.
Specifies the users or groups to whom you are giving DCADMIN privilege.
Specifies all users.
Important. If you grant DCADMIN to group PUBLIC, any user can administer security for the system.
Identifies a user or group.
Note: Expanded syntax for authorization-identifier is presented in Notes on Security Statement Syntax.
Decentralizing Administration
You can decentralize security administration for the system by granting DCADMIN and system definition privileges to other users.
A holder of SYSADMIN or DCADMIN can also specify WITH GRANT OPTION when granting system definition privileges to allow the recipient to grant the same privileges to others.
Granting DCADMIN to Administrators:
The following statement grants DCADMIN privilege to the security administrator ID and the DCA group ID:
grant dcadmin to secadmin, dca_group;
For more information about revoking DCADMIN privilege, see REVOKE Administration Privilege.
Gives one or more users or groups access to activities or categories.
To grant an execution privilege, you must hold one of these privileges:
►►─── GRANT EXECUTE ──────────────────────────────────────────────────────────► ┌─────────────── , ────────────────┐ ►─── ON ─┬─ ACTIVITY ─▼─ application-name.activity-name ─┴─────────┬─────────► │ ┌─────── , ───────┐ │ └─ CATEGORY ─▼─ category-name ─┴──────────────────────────┘ ┌─────────────── , ──────────────┐ ►─── TO ─▼─┬─ PUBLIC ───────────────────┬─┴──────────────────────────────────►◄ └─ authorization-identifier ─┘
Specifies that you are giving execution privilege to the users or groups identified in the TO parameter.
Specifies the resources to which execution privilege applies.
Specifies that you are giving execution privilege on one or more activities.
Identifies an activity.
Application-name.activity-name must have been previously defined as an activity with a CREATE RESOURCE statement.
You can wildcard activity-name. You cannot wildcard application-name. The wildcard character can appear in activity-name at any point after the period following application-name.
Note: For more information about wildcarding, see Using a Wildcard.
Specifies that you are giving execution privilege on one or more categories.
Identifies a category.
Category-name must have been previously defined as a category with a CREATE RESOURCE statement.
You can wildcard category-name.
Note: For more information about wildcarding, see Using a Wildcard.
Specifies the users or groups to whom you are giving execution privilege.
Specifies all users.
Identifies a user or group.
Note: Expanded syntax for authorization-identifier is presented in the chapter “Notes on Security Statement Syntax.”
Wildcarding Activity-Name
If you wildcard activity-name in a GRANT EXECUTE statement, you grant execution privilege on all activities whose names match the wildcarded name.
For example, this statement gives execution privilege on all DCMT activities whose names begin with 'VARY' to DCA_GROUP:
grant execute on activity dcmt.vary* to dca_group;
Adding Categories or Activities After a Grant
A category created after you grant privileges on the category with a wildcard is not included in the scope of the grant even if the resource name matches the wildcarded name. The wildcard is processed at the time the grant is made, not at runtime.
For example, if you create categories X1, X2, and X3, and then grant privileges on category X*, the three categories are within the scope of the grant. If you then create category X4, this category is not within the scope of the grant.
You can include X4 within the scope of the grant by revoking the original grant on category X* and then reissuing it.
The same considerations apply if you wildcard activity-name when granting execution privilege on an activity. The wildcard is processed at the time the grant is made, not at runtime.
Granting Execution Privilege on an Activity
The following statement grants execution privilege on a General Ledger activity to a development group:
grant execute on activity cgl.post to appldev1;
Granting Execution Privilege on a Category
The following statement grants execution privilege on the General Ledger category to all users:
grant execute on category glappl to public;
Granting Execution Privilege to PUBLIC
If execution privilege on a category has been granted to group PUBLIC, a user who has not signed on has the ability to invoke tasks and access other secured resources in the category.
For more information about revoking execution privilege, see REVOKE Execution Privilege.
Gives one or more users access to a CA IDMS system.
To issue the GRANT SIGNON statement, you must hold one of these privileges:
►►─── GRANT SIGNON ON SYSTEM system-identifier ──────────────────────────────► ►─┬──────────────────────────────┬──────────────────────────────────────────► └─ PROFILE ─┬─ profile-name ─┬─┘ └─ NULL ─────────┘ ┌─────────── , ─────────┐ ►─── TO ▼─── user-identifier ───┴───────────────────────────────────────────►◄
Specifies that you are giving signon privilege to the users identified in the TO parameter.
Identifies the system to which signon privilege applies.
System-identifier must have been defined as a resource with the CREATE RESOURCE SYSTEM statement.
Note: You cannot wildcard system-identifier.
Identifies the system profile to be used in signon processing.
Specifies that no system profile should be used in signon processing.
Identifies a user to whom you are giving signon privilege.
Changing the User's System Profile
To change the system profile associated with a user identifier:
Granting Signon with a Profile Specification
The following statement grants signon privilege and specifies the system profile to be invoked in signon processing:
grant signon on system syst0099 profile pub99 to sam;
Changing the User's System Profile
The following statements change user SAM's system profile to CORP99:
revoke signon on system syst0099 from sam; grant signon on system syst0099 profile corp99 to sam;
Gives to one or more users or groups the privilege to define a system or a system profile in the system dictionary.
To grant system definition privileges, you must hold one of these privileges:
►►─── GRANT ─┬─ DEFINE ──────────┬────────────────────────────────────────────► │ ┌────── , ──────┐ │ └─▼─┬─ ALTER ───┬─┴─┘ ├─ CREATE ──┤ ├─ DISPLAY ─┤ └─ DROP ────┘ ►─── ON ─┬─ SYSTEM system-identifier ────┬───────────────────────────────────► └─ SYSTEM PROFILE profile-name ─┘ ┌─────────────── , ──────────────┐ ►─── TO ─▼─┬─ PUBLIC ───────────────────┬─┴──────────────────────────────────► └─ authorization-identifier ─┘ ►─┬─────────────────────┬────────────────────────────────────────────────────►◄ └─ WITH GRANT OPTION ─┘
Gives the ALTER, CREATE, DISPLAY, and DROP privileges on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
The DEFINE privilege on a system allows the user to use the CA IDMS system generation compiler to add, modify, or delete the system. The DEFINE privilege also allows the user to display or punch the definition of the system.
The DEFINE privilege on a system profile allows the user to create, alter, or drop a system profile, or to display security definitions for the system profile.
Gives the ALTER privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
The ALTER privilege on a system allows a user to use the system generation compiler to modify the definition of the system.
The ALTER privilege on a system profile allows a user to alter the system profile.
Gives the CREATE privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
The CREATE privilege on a system allows a user to use the system generation compiler to add the system.
The CREATE privilege on a system profile allows a user to create the system profile.
Gives the DISPLAY privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
The DISPLAY privilege allows the user to issue a DISPLAY RESOURCE statement on the named system or system profile. The grantable DISPLAY privilege allows a user to issue a DISPLAY PRIVILEGES statement on the named system or system profile.
The DISPLAY privilege on a system also allows a user to use the system generation compiler to display or punch the system definition.
Gives the DROP privilege on the resource identified in the ON parameter to the users or groups identified in the TO parameter.
The DROP privilege on a system allows a user to use the system generation compiler to delete the definition of the system.
The DROP privilege on a system profile allows a user to drop the system profile.
Specifies the resource to which the definition privileges apply.
Identifies a system.
You can wildcard system-identifier.
Note: For more information about wildcarding, see Using a Wildcard.
If you do not wildcard system-identifier, the value you specify must match the identifier of a system secured with the CREATE RESOURCE SYSTEM statement.
Identifies a system profile.
Note: For more information about creating system profiles, see the CA IDMS System Tasks and Operator Commands Guide.
You can wildcard system-profile.
Note: For more information about wildcarding, see Using a Wildcard.
Specifies the users or groups to whom you are giving the definition privileges.
Specifies all users.
Identifies a user or group.
Note: Expanded syntax for authorization-identifier is presented in the chapter Notes on Security Statement Syntax.
Gives the privilege of granting the specified definition privileges to the users or groups identified in the TO parameter.
A privilege granted with the WITH GRANT OPTION is called a grantable privilege.
The DEFINE Keyword
When you use the DEFINE keyword with a GRANT statement, you grant a set of definition privileges on a resource to one or more users or groups.
When you use the DEFINE keyword with a REVOKE statement, you revoke all definition privileges that have been previously granted on the resource from the specified users or groups.
This means that if you GRANT CREATE privilege on a resource, you can revoke the privilege with either a REVOKE CREATE statement or a REVOKE DEFINE statement. Using REVOKE DEFINE is an efficient technique when you intend to revoke all definition privileges on the resource from a user or group, whether the privileges were granted singly or as a set.
Similarly, you can GRANT DEFINE on a resource to a user and then REVOKE DROP on the resource from the same user as a way to grant all but one definition privilege.
Granting Privilege to Define the System
The following statement grants the privilege to define a system to the system DCA:
grant define on system syst0099 to dca0099;
Revokes DCADMIN privilege from one or more users or groups.
To revoke DCADMIN privilege, you must hold one of these privileges:
►►─── REVOKE DCADMIN ─────────────────────────────────────────────────────────► ┌─────────────── , ──────────────┐ ►─── FROM ─▼─┬─ PUBLIC ───────────────────┬─┴────────────────────────────────►◄ └─ authorization-identifier ─┘
Specifies that you are revoking DCADMIN privilege from the users or groups named in the FROM parameter.
Specifies the users or groups from whom you are revoking DCADMIN privilege.
Specifies all users.
Identifies a user or group.
The privilege must have been previously given to authorization-identifier by means of the GRANT statement.
Note: Expanded syntax for authorization-identifier is presented in chapter “Notes on Security Statement Syntax."
Revoking DCADMIN from Administrators
The following statement revokes DCADMIN privilege from the DCA group ID:
revoke dcadmin from dca_group;
For more information about granting DCADMIN privilege, see GRANT Administration Privilege.
Revokes from one or more users or groups the privilege to access an activity or category.
To revoke execution privilege, you must hold one of these privileges:
►►─── REVOKE EXECUTE ─────────────────────────────────────────────────────────► ┌──────────────── , ───────────────┐ ►─── ON ─┬─ ACTIVITY ─▼─ application-name.activity-name ─┴──────────┬────────► │ ┌─────── , ───────┐ │ └─ CATEGORY ─▼─ category-name ─┴───────────────────────────┘ ┌─────────────── , ──────────────┐ ►─── FROM ─▼─┬─ PUBLIC ───────────────────┬─┴────────────────────────────────►◄ └─ authorization-identifier ─┘
EXECUTE
Specifies that you are revoking execution privilege from the users or groups identified in the FROM parameter.
Specifies the resource to which execution privilege applies.
Specifies that you are revoking execution privilege on one or more activities.
Identifies an activity.
You can wildcard activity-name. You cannot wildcard application-name. The wildcard character can appear in activity-name at any point following the period after application-name.
Note: For more information about wildcarding, see Using a Wildcard.
Specifies that you are revoking execution privilege on one or more categories.
Identifies a category.
Specifies the users or groups from whom you are revoking execution privilege.
Specifies all users.
Identifies a user or group.
The privilege must have been previously given to authorization-identifier by means of the GRANT statement.
Note: Expanded syntax for authorization-identifier is presented in the chapter Notes on Security Statement Syntax.
Revoking Execution Privilege on an Activity
The following statement revokes execution privilege on a General Ledger activity from a development group:
revoke execute on activity cgl.post from appldev1;
Revoking Execution Privilege on a Category
The following statement revokes execution privilege on the General Ledger category from PUBLIC:
revoke execute on category glappl from public;
For more information about granting execution privilege, see GRANT Execution Privilege.
Revokes the privilege to access a system from one or more users.
To revoke signon privilege, you must hold one of these privileges:
►►─── REVOKE SIGNON ON SYSTEM system-identifier ──────────────────────────────► ┌────────── , ──────────┐ ►─── FROM ─▼─── user-identifier ───┴─────────────────────────────────────────►◄
Specifies that you are revoking signon privilege to the system identified in the ON parameter from the users identified in the FROM parameter.
Identifies the system to which the signon privilege applies.
Identifies a user from whom you are revoking signon privilege.
The privilege must have been previously given to user-identifier by means of the GRANT statement.
Revoking Signon
The following statement revokes signon privilege on a specified system from a user:
revoke signon on system syst0099 from sam;
For more information about granting signon privilege, see GRANT Signon Privilege.
Revokes from one or more users or groups the privilege to define a system or a system profile in the system dictionary.
To revoke system privileges, you must hold one of these privileges:
►►─── REVOKE ─┬─ DEFINE ──────────┬───────────────────────────────────────────►
│ ┌────── , ──────┐ │
└─▼─┬─ ALTER ───┬─┴─┘
├─ CREATE ──┤
├─ DISPLAY ─┤
└─ DROP ────┘
►─── ON ─┬─ SYSTEM system-identifier ────┬───────────────────────────────────►
└─ SYSTEM PROFILE profile-name ─┘
┌─────────────── , ──────────────┐
►─── FROM ─▼─┬─ PUBLIC ───────────────────┬─┴────────────────────────────────►◄
└─ authorization-identifier ─┘
Revokes the ALTER, CREATE, DISPLAY, and DROP privileges on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
Revokes the ALTER privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
Revokes the CREATE privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
Revokes the DISPLAY privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
Revokes the DROP privilege on the resource identified in the ON parameter from the users or groups identified in the TO parameter.
Specifies the resource to which the definition privileges apply.
Identifies a system.
Identifies a system profile.
Specifies the users or groups from whom you are revoking the specified definition privileges.
Specifies all users.
Identifies a user or group.
The privileges must have been previously given to authorization-identifier by means of the GRANT statement.
Note: Expanded syntax for authorization-identifier is presented in the chapter “Notes on Security Statement Syntax."
The DEFINE Keyword
When you use the DEFINE keyword with a GRANT statement, you grant a set of definition privileges on a resource to one or more users or groups.
When you use the DEFINE keyword with a REVOKE statement, you revoke all definition privileges that have been previously granted on the resource from the specified users or groups.
This means that if you GRANT CREATE privilege on a resource, you can revoke the privilege with either a REVOKE CREATE statement or a REVOKE DEFINE statement. Using REVOKE DEFINE is an efficient technique when you intend to revoke all definition privileges on the resource from a user or group, whether the privileges were granted singly or as a set.
Similarly, you can GRANT DEFINE on a resource to a user and then REVOKE DROP on the resource from the same user as a way to grant all but one definition privilege.
Revoking Privilege to Define the System
The following statement revokes the privilege to define a system from the system DCA:
revoke define on system syst0099 from dca0099;
|
Copyright © 2014 CA.
All rights reserved.
|
|