1  DEFINE_PROTECTION
   Adds an entry to the access control list (ACL) for a database,
   relation, view or view. To define protection for a database, you
   must first invoke the database.

   Example:

   RDO>  DEFINE PROTECTION FOR DATABASE
   cont>   POSITION 3
   cont>   IDENTIFIER [25,235]
   cont>   ACCESS "READ+WRITE+MODIFY+ERASE".
 

2  Format

 (B)0DEFINE PROTECTION FOR qqqqk
                           x
      lqqqqqq<qqqqqqqqqqqqqj
      mqqqqwqqq> DATABASE qqqqqqqqqqq>qqqqqqqqqqqqqqqqqk
           tqqq> RELATION qq> relation-name qqqqqqqqqqqu
           tqqq> VIEW qqqqqq> view-name qqqqqqqqqqqqqqqu
           mqqq> FIELD q> field-name IN relation-name qu
       lqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
       mqqqwqqqqqqqqqqq>qqqqqqqqqqqqqqqqqqwqk
           tq> AFTER qqq> identifier qqqqqu x
           mq> POSITION qq> n qqqqqqqqqqqqj x
         lqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqqj
         mqqq> IDENTIFIER qqwqq> identifier qqwqk
                            mqq<qqqq + <qqqqqqj x
         lqqqqqqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqj
         mqqq> ACCESS qqqwqqq>qqqqqqqqqqqqqqqqqwqqqqqqqqqq> .
                         mqwq> access-right qwqj
                           mq<qqqqqq + <qqqqqj

 

3  relation-name
   The name of the Oracle Rdb relation for which you want to insert an
   ACL entry (ACE).

   A user with MODIFY rights on the relation automatically gets
   the same rights on all fields in the relation. However, you can
   restrict MODIFY rights by defining them only on specific fields
   you want users to be able to modify and thus remove the right
   from the relation entry.
 

3  view-name
   The name of the Oracle Rdb view for which you want to insert an ACL
   entry.
 

3  field-name
   The name of the local field in a specified relation for which you
   want to insert an ACL entry.

   Rights on a field are determined by the rights defined on the
   field combined with those specified for the specific relation
   ACL.

   Only MODIFY rights can be granted to fields. All other rights are
   not applicable.
 

3  AFTER
   Locates the new ACL entry relative to an existing entry. When you
   specify an identifier, Oracle Rdb searches the access control list
   for an existing entry that matches. It then inserts the new entry
   after the existing one. If you use the AFTER clause, you cannot
   use the POSITION clause.
 

3  POSITION
   Locates a new ACL entry relative to its position in the list.
   Use an unsigned integer greater than zero to specify the position
   in the access control list where Oracle Rdb places a newly created
   entry. If you use the POSITION clause, you cannot use the AFTER
   clause.

   When this statement executes, Oracle Rdb automatically reassigns
   sequence numbers to entries in the ACL, starting with number one.
 

3  IDENTIFIER
   Identifies the user or users for whom an entry is being added.
   You can specify any valid OpenVMS identifier in the identifier
   clause:

   o  UIC identifier

      You cannot specify more than one UIC identifier in a DEFINE
      PROTECTION statement.

   o  General identifier

   o  System-defined identifier
 

4  More
   You can specify multiple identifiers in the identifier clause
   when combining an identifier with a system-defined identifier.
   However, you should regard the six system-defined identifiers
   as mutually exclusive. Do not attempt to use them in combination
   with each other. You can combine them with other identifiers
   (UICs and general identifiers). When you specify multiple
   identifiers, separate them with a plus sign (+).

   If you specify multiple identifiers in the identifier clause,
   you define one ACE that determines the access rights that users
   will receive when they hold ALL the identifiers specified in the
   identifier clause. Users who do not hold all of the identifiers
   specified in the identifier clause will not be governed by the
   ACE that is created.

   For example, the first of the two RDO statements in the
   following example defines a single ACE for users with both the
   [CLERK,DAVIES] and REMOTE identifiers, not one ACE for users with
   the [CLERK,DAVIES] identifier and another ACE for users with the
   REMOTE identifier. The second statement shows the ACE created
   in the second position in the ACL, as specified in the DEFINE
   PROTECTION statement:


   DEFINE PROTECTION FOR RELATION A1
   POSITION 2
   IDENTIFIER [CLERKS,DAVIES]+REMOTE
   ACCESS READ+WRITE+MODIFY.
   !
   SHOW PROTECTION FOR RELATION A1
    (IDENTIFIER=[DBS,RICK],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+
      CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR+REFERENCES+SECURITY)
    (IDENTIFIER=[CLERK,DAVIES]+REMOTE,ACCESS=READ+WRITE+MODIFY)
    (IDENTIFIER=[*,*],ACCESS=READ+MODIFY)

   To control which users have the ability to create databases, use
   the RDBVMS$CREATE_DB logical name and system rights identifier.
   See the "Oracle Rdb Guide to Database Design and Definition" for
   more information on the RDBVMS$CREATE_DB logical name and system
   rights identifier.
 

3  ACCESS
   Grants or denies access rights to the user identified in an ACL
   entry. For more information on access rights, ask for HELP on
   Access_rights.

   Specify only those access rights that you want to grant access
   to.
 

2  More
   You must have the Oracle Rdb CONTROL privilege for an object to
   define protection for the object using the DEFINE PROTECTION
   statement.

   An access control list (ACL) is attached to each database,
   relation, and view. This list defines which users can access
   the database element and what operations each user can perform.
   Thus each entry in the access control list consists of two items
   of information:

   o  An identifier that specifies a user or set of users.

   o  A set of access rights. These rights specify what operations
      the user or users can perform on the database or relation.

   When you first create a database, Oracle Rdb creates two ACL
   entries, one for the creator of the database and one for all
   other users. Under the Oracle Rdb default protection scheme,
   the creator of the database is given all access rights to the
   database, including CONTROL, which enables the owner to grant
   CONTROL and any other access rights to other users. All other
   users of the database are given no access rights to the database.
   For any relations or views created under the Oracle Rdb default
   protection scheme, the creator of the relation or view is given
   all the access rights to the object, including CONTROL, and all
   other users are given no access rights to the relation.

   Oracle Rdb allows you to tailor the default protection for any new
   relations that are created in a database:

   1. By default, the creator of a relation gets all the access
      rights to the relation, but Oracle Rdb gives no access to any
      other user:

      RDO> SHOW PROTECTION FOR RELATION RELATION1
          (IDENTIFIER=[DBS,RICK],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+
            CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR+REFERENCES)
          (IDENTIFIER=[*,*],ACCESS=NONE)

   2. If you want other users to have some access to new relations,
      you can define an identifier called DEFAULT in the system
      rights database. Then you can define an identifier called
      DEFAULT for your Oracle Rdb database. The access rights specified
      in the DEFAULT identifier will be granted to all users except
      the owner of any new relations created in the database. For
      example:

      RDO> DEFINE PROTECTION FOR DATABASE
      cont> IDENTIFIER DEFAULT
      cont> ACCESS READ+MODIFY.

   3. You need to detach from the database to make the change in
      protection occur:

      RDO> COMMIT
      RDO> FINISH

   4. The protection on existing relations in the database is not
      changed, but any new relations that are defined receive
      the protection specified by the DEFAULT identifier. In this
      example, the creator receives all the access rights to the new
      relation RELATION2 and all other users receive the READ and
      MODIFY access rights specified by the DEFAULT identifier.

      RDO> INVOKE DATABASE FILENAME TEST1
      RDO>
      RDO> DEFINE RELATION RELATION2.
      cont> FIELD1.
      cont> FIELD2.
      cont> END RELATION.
      RDO>
      RDO> SHOW PROTECTION FOR RELATION RELATION2
          (IDENTIFIER=[DBS,RICK],ACCESS=READ+WRITE+MODIFY+ERASE+SHOW+DEFINE+
            CHANGE+DELETE+CONTROL+OPERATOR+ADMINISTRATOR+REFERENCES)
          (IDENTIFIER=[*,*],ACCESS=READ+MODIFY)

   Oracle Rdb determines the rights for a user by matching the user's
   user identification code (UIC) with the identifier in each ACL
   entry. The first time Oracle Rdb finds a match, it grants the user
   the rights in that entry. If there is no match, Oracle Rdb grants
   no rights. Therefore, if the creator deletes the second default
   entry whose identifier is [*,*], all access is denied to all
   users but the creator.

   Use the DEFINE PROTECTION statement to add more entries to the
   list. When the statement executes, Oracle Rdb creates a new entry
   in the position specified. This entry grants the specified rights
   to the user or group of users determined by the identifier. All
   rights not specified in the statement are denied.

   For a particular user, Oracle Rdb grants an access right to a
   relation only if that right is granted in the ACL for both the
   database and the relation. That is, a user has WRITE privilege
   to the EMPLOYEES relation only if that user has WRITE privilege
   to both the PERSONNEL database and the EMPLOYEES relation. This
   means that protection at the database level should grant to each
   user or group of users all the privileges they may need for any
   relation. You can then deny these privileges at the relation
   level.

   Granting or revoking a privilege takes effect after the user
   detaches and attaches to the database again.

   To define protection for a database, you must first invoke the
   database. You must execute the DEFINE PROTECTION statement in a
   read/write transaction. If you issue this statement when there
   is no active transaction, Oracle Rdb starts a read/write transaction
   implicitly.

   Other users are allowed to be attached to the database when you
   issue the DEFINE PROTECTION statement.

   You must have the READ database privilege to attach to a
   database.

   The ADMINISTRATOR, OPERATOR, and SECURITY database privileges
   are the three Oracle Rdb role-oriented privileges. Users with these
   privileges have the ability to override ACLs for some objects
   to perform database operations. Similarly, users with certain
   OpenVMS privileges also have the ability to override ACLs for
   some database objects. The Oracle Rdb role-oriented privileges
   are limited to the database in which they are granted, but the
   OpenVMS privileges span all databases on the system.

   Users with the Oracle Rdb or the OpenVMS role-oriented privileges
   are implicitly granted other Oracle Rdb privileges. When you are
   granted implicit privileges to a database object as a result
   of an ACL override, you operate as if you actually hold the
   privilege, although you are not explicitly granted the privilege
   and it is not stored in the ACL.

   Users with the ADMINISTRATOR database privilege or the OpenVMS
   SYSPRV privilege can perform any data definition or data
   manipulation operation on any named object, including the
   database, regardless of the ACL for the object. The ADMINISTRATOR
   privilege is the most powerful privilege in Oracle Rdb, since it
   can override most privilege checks performed by Oracle Rdb. Users
   with the ADMINISTRATOR database privilege or the OpenVMS SYSPRV
   privilege implicitly receive ALL privileges for all objects,
   except the SECURITY and OPERATOR database privileges.

   Users with the OPERATOR database privilege or the OpenVMS OPER
   privilege implicitly receive the Oracle Rdb READ, WRITE, MODIFY, and
   ERASE database privileges.

   Users with the SECURITY database privilege or the OpenVMS
   SECURITY privilege implicitly receive the Oracle Rdb READ, WRITE,
   MODIFY, and ERASE database privileges.

   Users with the OpenVMS BYPASS privilege implicitly receive
   ALL privileges except the Oracle Rdb ADMINISTRATOR, OPERATOR, and
   SECURITY database privileges and the CONTROL relation privilege.

   Users with the OpenVMS READALL privilege receive implicit READ
   and SHOW database and relation privileges.

   You must have the DISTRIBTRAN database access right to a database
   to run a two-phase commit transaction on that database.
 

2  Examples
   Example 1

   The following example grants access rights to a single user:

   RDO>  DEFINE PROTECTION FOR DATABASE
   cont> POSITION 3
   cont> IDENTIFIER [CLERKS,DAVIES]
   cont> ACCESS "READ+WRITE+MODIFY+ERASE".

   This statement performs the following actions:

   o  Specifies the location of the entry within the access
      control list. The new entry is in the third position and all
      subsequent entries are moved to the next higher position.

   o  Uses an identifier to designate the user who is granted access
      rights.

   o  Grants the specified access rights. Oracle Rdb denies all other
      rights.

   Example 2

   The following example grants access rights to a group of users:

   RDO>  DEFINE PROTECTION FOR RELATION SALARY_HISTORY
   cont>      AFTER [ANALYSTS,JOHNSON]
   cont>      IDENTIFIER [ANALYSTS,*]
   cont>      ACCESS
   cont>      "READ+WRITE+MODIFY+ERASE -
   cont>      +DEFINE+CHANGE+DELETE".

   This statement performs the following actions:

   o  Names the relation SALARY_HISTORY. The new ACL entry will be
      applied to this relation.

   o  Uses the AFTER clause to specify the location of the entry
      within the ACL. In this case, the new ACL entry appears after
      the entry for user identifier [ANALYSTS,JOHNSON].

   o  Identifies the set of users ([ANALYSTS,*]) who are granted the
      listed access rights. In this case, the new identifier has the
      same group identifier as the identifier that precedes it in
      the list. This means that for user JOHNSON in group ANALYSTS,
      Oracle Rdb will grant the privileges listed in the earlier
      entry. All other users in group ANALYSTS will fall through
      to the entry identified by [ANALYSTS,*]. Oracle Rdb grants these
      other members of group PROGRAMMERS the rights listed in this
      statement. In this way, the system gives general rights to
      a group and more specific rights to a single member of the
      group.

   Example 3

   The following example grants access rights on the specific field
   to a group of users:

   RDO>  DEFINE PROTECTION FOR FIELD SALARY_AMOUNT IN SALARY_HISTORY
   cont>      AFTER [MANAGERS,SMITH]
   cont>      IDENTIFIER [MANAGERS,*]
   cont>      ACCESS MODIFY.

   The following examples show how to specify the identifiers in a
   DEFINE PROTECTION statement.

   Example 4

   In this example, all users with the UIC matching [25,*] and
   running a batch job are granted the access rights listed.

   RDO>  DEFINE PROTECTION FOR DATABASE
   cont> POSITION 4
   cont> IDENTIFIER [25,*]+BATCH
   cont> ACCESS READ+DEFINE+CHANGE+DELETE.

   2 Example 5

   All users associated with the general identifier DATAENTRY and
   using RDO interactively are granted update access rights.

   RDO>  DEFINE PROTECTION FOR DATABASE
   cont> POSITION 5
   cont> IDENTIFIER DATAENTRY+INTERACTIVE
   cont> ACCESS READ+WRITE+MODIFY+STORE.

   Example 6

   User JONES gets the specified access rights.

   RDO> DEFINE PROTECTION FOR DATABASE
   cont> POSITION 6
   cont> IDENTIFIER [RDB,JONES]
   cont> ACCESS READ+WRITE+MODIFY+ERASE.