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.