The ACLs attached to the CDS namespace at configuration are described in OSF DCE Administration Guide. The following ACL permissions are defined for CDS objects. The single letter in parentheses for each item represents the DCE notation for that permission. These single letters are identical to the untokenized forms returned by sec_acl_get_printstring( ).
· read (r)
This permission allows a principal to look up an object entry and view its attribute values.
· write (w)
This permission allows a principal to change an object's modifiable attributes, except for its ACLs.
· insert (i)
This permission allows a principal to create new entries in a CDS directory. It is used with directory entries only.
· delete (d)
This permission allows a principal to delete a name entry from the namespace.
· test (t)
This permission allows a principal to test whether an attribute of an object has a particular value, but does not permit it actually to see any of the attribute values (in other words, read permission for the object is not granted). The test permission allows an application to verify a particular CDS attribute's value without reading it.
· control (c)
This permission allows a principal to modify the entries in the object's ACL. The control permission is automatically granted to the creator of a CDS object.
· administer (a)
This permission allows a principal to issue cdscp commands that control the replication of directories. It is used with directory entries only.
Detailed instructions on the mechanics of setting up ACLs on CDS objects can be found in the OSF DCE Administration Guide.
For CDS directories, read and test permissions are sufficient to allow ordinary principals to access the directory and to read and test entries therein. Principals who you want to be able to add entries in a CDS directory should have insert permission for that directory. Entries created by the RPC NSI routines (for example, when a server exports bindings for the first time) are automatically set up with the correct permissions. However, if you are creating new CDS directories for RPC use, you should be sure to grant prospective user principals insert permission to the directory so that servers can create entries when they export their bindings. A general list of the permissions required for the various RPC NSI operations can be found in the rpc_intro(3rpc) and rpc_ns_*(3rpc) (RPC NSI) reference pages.
Note that CDS names do not behave the same way as file system names. A principal does not have to have access to an entire entry name path in order to have access to an entry at the end of that path. For example, a principal can be granted read access to the following entry:
/.:/applications/utilities/pr2
and yet not have read access to the utilities directory itself.