Format
DEFINE PROTECTION FOR
{ DIRECTORY }
{ FIELD }
{ RECORD } element-name ,...
{ }
{ GENERIC type-name }
[ POSITION n ]
[ AFTER id1+ ... ] IDENTIFIER id2+... ACCESS
[ ]
right+ ... .
{ REPOSITORY anchor-name }
DEFINE PROTECTION FOR { GENERIC MCS_CONTEXT context-name }
{ }
[ POSITION n ] IDENTIFIER id2
{ ACCESS }
{ DEFAULT_ACCESS } right+ ... .
{ }
1 – Parameters
1.1 – type-name
Specifies the type of the generic element whose ACE you are
defining.
1.2 – element-name
Specifies the element whose ACE you are defining. You can use
wildcard characters in this name.
1.3 – n
Specifies the relative position (a positive integer) in the ACL
of the ACE you are defining. If you omit the position or the
identifier, the ACE you are defining becomes the first ACE in the
ACL.
1.4 – id1
Specifies the identifier or identifiers of the existing ACE that
will immediately precede the ACE you are defining.
1.5 – id2
Specifies the identifier or identifiers of those users whose
access to the element or repository you are defining in this ACE.
1.6 – right
Specifies the access rights CDO grants to the users you specified
in id2.
1.7 – anchor-name
Specifies the anchor directory of the repository whose ACE you
are defining.
1.8 – context-name
Specifies the context.
2 – Description
The DEFINE PROTECTION command adds an access control list
entry (ACE) to the access control list (ACL) of an element or
repository. When you specify FOR GENERIC MCS_CONTEXT or FOR
REPOSITORY, this command can also add an ACE to a default access
control list. To define protection, you need CONTROL access.
The ACEs in an ACL determine which users can access the element
or repository and what operations each user can perform. An ACE
consists of the following two parts:
o One or more identifiers that specifies a user or set of users:
UIC, general, and system-defined
o A set of access rights: READ, WRITE, EXECUTE, and DELETE
The POSITION clause specifies the relative position CDO assigns
your ACE in the ACL. ACEs are numbered in ascending order
starting with number one. If you specify a number that is larger
than the number of ACEs in the ACL, the ACE you are creating
becomes the last entry in the ACL.
The AFTER clause specifies the identifiers of an existing ACE
that will immediately precede the ACE that you are defining.
The IDENTIFIER clause specifies the identifiers of the user or
users whose access to the element or repository you are defining
in this ACE. If an ACE contains more than one identifier, a
user's process must hold all the identifiers specified in the
ACE to receive the access rights granted by the ACE.
The ACCESS clause specifies the rights that the ACE provides.
This clause is especially useful when you need to restrict access
to a context or to a repository. For example, by modifying this
clause, you can restrict access to a single user for OpenVMS
BACKUP or VERIFY operations.
The DEFAULT_ACCESS clause is only valid for contexts (specified
as GENERIC MCS_CONTEXT) or repositories. The clause specifies
the default access rights for each new element you create.
If a context is set, the new element receives default access
rights defined for this context. If a context is not set, the
new element receives the default access rights defined for the
repository.
For complete information on defining protection, see Using Oracle
CDD/Repository on OpenVMS Systems.
3 – Examples
1.CDO> DEFINE PROTECTION RECORD PERSONNEL
cont> POSITION 2
cont> IDENTIFIER [JONES,DICT]+LOCAL+INTERACTIVE
cont> ACCESS READ+WRITE+DELETE.
In this example, the DEFINE PROTECTION command creates a new
second ACE for the PERSONNEL record. The former second ACE
becomes the new third ACE.
2.CDO> DEFINE PROTECTION FOR RECORD PERSONNEL
cont> AFTER [JONES,DICT]+LOCAL+INTERACTIVE
cont> IDENTIFIER [CDD,SMITH] ACCESS READ.
In this example, the DEFINE PROTECTION command inserts a new
ACE with the identifier [CDD,SMITH] after the ACE with the
[JONES,DICT]+LOCAL+INTERACTIVE identifiers.
3.CDO> DEFINE PROTECTION FOR RECORD BENEFITS.*;* POSITION 4
cont> IDENTIFIER [PERSONNEL,*] ACCESS SHOW.
In this example, the DEFINE PROTECTION command creates a fourth
ACE for all current records in the BENEFITS directory. This ACE
does not become the default protection for definitions that are
subsequently created.
4.CDO> DEFINE PROTECTION FOR RECORD PERSONNEL
cont> IDENTIFIER [*,*] ACCESS NONE.
In this example, the DEFINE PROTECTION command creates an ACE
that denies all access rights to all users. CDO places this
ACE first in the ACL, because the user did not specify either a
POSITION clause or an AFTER clause in the command. As a result,
everyone (including the user who issued the command) is denied
all access to the definition.
Only the owner can regain access to the definition by using
either the DELETE PROTECTION or CHANGE PROTECTION command to
remove or change the ACE.
5.CDO> DEFINE PROTECTION FOR REPOSITORY PERSONNEL
cont> POSITION 2 IDENTIFIER [SYSTEM]
cont> ACCESS READ+WRITE+DELETE+CONTROL.
In this example, the DEFINE PROTECTION command creates an
ACE in the second position that grants the SYSTEM user
READ+WRITE+DELETE+CONTROL access.
6.CDO> DEFINE PROTECTION FOR REPOSITORY PERSONNEL
cont> POSITION 2 IDENTIFIER [*,*]
cont> DEFAULT_ACCESS READ+WRITE.
CDO> DEFINE FIELD NEW_FIELD DATATYPE TEXT SIZE 5.
In this example, the DEFINE PROTECTION command defines
the default access rights for the PERSONNEL repository to
READ+WRITE. If a context has not been set, CDO will grant the
newly created field, NEW_FIELD, with access rights that are
equivalent to the repository's default access rights.
7.CDO> DEFINE PROTECTION FOR REPOSITORY CDD$REPOSITORY2
cont> POSITION 2 IDENTIFIER [*,*]
cont> ACCESS NONE.
In this example, the DEFINE PROTECTION command defines the
access rights for the repository using a logical name for the
repository name.
4 – Protecting the Repository Anchor
Oracle CDD/Repository places a security ACL on repository anchors
when a new repository is created, when a repository is moved,
or when the location of the repository is changed with the CDO
command VERIFY/LOCATION/FIX.
The ACL is as follows:
(IDENTIFIER=CDD$SYSTEM,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=[*,*],ACCESS=READ+EXECUTE)
(IDENTIFIER=CDD$SYSTEM,OPTIONS=DEFAULT+NOPROPAGATE,ACCESS=READ
+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=[*,*],OPTIONS=DEFAULT+NOPROPAGATE,ACCESS=NONE)
To add these ACLs to existing repository anchors on your system,
you can use either one of the following methods:
o OpenVMS SET ACL/ACL command
o ACL Editor
In addition to this default protection, you should add UIC-based
protection with either of the following commands:
o OpenVMS SET PROTECTION command
o OpenVMS CREATE/DIRECTORY/PROTECTION command
For more information about setting OpenVMS protection on a
repository's OpenVMS anchor directory, see the OpenVMS Examples
at the end of this section.
4.1 – Examples
Example 1:
$ SET ACL/ACL=(IDENTIFIER=CDD$SYSTEM, -
_$ ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) [SMITH]DIC.DIR(1)
$ SET ACL/ACL=(IDENTIFIER=[*,*],ACCESS=READ) [SMITH]DIC.DIR(1)
Protect your repository anchor directory with an ACL containing
the ACEs shown in the previous example. With these ACEs, only
repository files can be created in a repository anchor directory.
In this example, the SET ACL/ACL command, creates an ACL for the
OpenVMS anchor directory of the [SMITH.DIC] repository:
Example 2:
$ SET ACL/EDIT [SMITH]DIC.DIR(1)
$ EDIT/ACL [SMITH]DIC.DIR(1)
You might find it easier to use the ACL Editor to create an
ACL for an OpenVMS anchor directory by using either one of the
following DCL commands:
Example 3:
$ SHOW ACL [SMITH]DIC.DIR(1)
element type: file, element name: CDD$DISK:[SMITH]DIC.DIR(1),
on 27-FEB-1989 09:54:40.62
(IDENTIFIER=CDD$SYSTEM,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=[*,*],ACCESS=READ)
To display the ACL you just created, use the DCL SHOW ACL
command:
Example 4:
$ SET PROTECTION=(S:RWED,,,) [SMITH]DIC.DIR(1)
You should also add UIC-based protection to your repository's
OpenVMS anchor directory. In this example, the DCL SET PROTECTION
command creates UIC-based protection for the OpenVMS anchor
directory [SMITH.DIC].