Documentum Content Server version 6.6 introduced a new feature, “Owner Minimum Permissions”, which allows the minimum permissions for owners to be set across the repository. These permissions would override any ACL based calculations – no ACL could reduce the effective owner permissions to be more restrictive than the ones set up in this configuration. Note that version 5.3 also has a similar behavior except that the owner minimum permissions are fixed (not configurable) – READ and all extended permissions other than EXTENDED DELETE.
It has been confirmed that this feature does not work as expected in version 6.6. At least for one operating system and database combination, these settings have no effect and the behavior is identical to 5.3. It is quite likely that this problem is not restricted to this one environment configuration.
EMC Documentum Content Server Version 6.5 Fundamentals has a big error about ACLs on page 134.
As highlighted in the figure above, it claims that ACLs assigned to folders are not used to define access to the folder. This is an incorrect statement. All you need to do to test this statement is to create a folder, alter permissions on it so that you have an effective permission of less than DELETE and then try to delete the folder. You will see that the deletion fails. Similarly, BROWSE permission is needed to look at a folder’s attributes and to retrieve it in query results.
Apparently, the intent is to explain the special usage of ACLs assigned to folders as mentioned in the last statement in the screenshot. However, that is in addition to and not instead of the regular effects of ACLs. In addition to controlling access to the folder object, the ACL assigned to it is used for enforcing folder security (if enabled), which restricts operations on objects linked to the folder. Further, when the default ACL mode for a Content Server instance is Folder, new objects created by that instance in the folder are assigned the same ACL as the one on the folder, by default. This is also loosely referred to as inheriting ACL from folder.
A Documentum Architecture whitepaper is available on EMC Documentum Developer Community site – EMC Documentum Architecture: Delivering the Foundations and Services for Managing Content Across the Enterprise. A part of page 13 from the currently posted version (dated January 2008, a newer version will probably fix this issue) is shown below. It describes object-level security in a confusing manner.
The areas of concern are marked in the image. These concerns are explained below:
Under Basic Permissions, it states that Delete is a special case with regard to the cumulative property. This is an incorrect assertion. The Delete basic permission does imply all the other lower basic permissions.
The section title – “Object-level delete privileges” is inconsistent with Documentum terminology. Privileges are associated with users and permissions are associated with objects being secured.
“Delete Object permission” should be “Delete Object extended permission” to be unambiguously correct. It is not the basic delete permission, which is suggested by the last sentence of the previous section.
Two Extended Permissions are missing in the list – Delete Object and Change Folder Links. The Delete Object extended permission is actually what is explained under the title “Object-level delete privileges” above. The Change Folder Links extended permission was introduced in Documentum 6. It enables linking to and unlinking from a folder.