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.
Suppose that a senior manager needs to be able to read all the documents in a Documentum repository. This ability should apply not only to the existing documents in the repository but also to documents that may be created/imported in future.
Without a special mechanism, such a requirement would lead to some group being added to all the ACLs used by documents. Documentum 6.5 SP2 introduced a built-in group dm_read_all, which has READ access to any sysobject in the repository regardless of the ACL assigned to the object. Similarly, the dm_browse_all group (this existed in versions before 6.0), has BROWSE access on all the sysobjects in the repository.
Thus our requirement can be met by simply adding the user to dm_read_all.
I discovered another erroneous statement in Documentum Content Server 6.5 Fundamentals. This one relates to changing permissions on an object and occurs on Page 189. The statement in question is highlighted below.
It states that at least WRITE permission is required to replace the ACL assigned to an object.
The fact is that the ACL cannot be replaced without Change Permission extended permission. Further, BROWSE is sufficient among basic permissions and WRITE is not needed for this purpose. We cannot do much to an object without BROWSE permission so that’s the minimum needed. Of course, basic permissions higher than BROWSE (i.e. READ, RELATE, VERSION, WRITE, DELETE) will also work because they imply BROWSE permission.
It is pretty easy to verify with Webtop. Make sure that the effective permissions – labeled as Your Permissions, on the Permissions properties tab indicate BROWSE and Change Permission and you will be able to select a different ACL and save the object.
Therefore the correct statement should be: Replacing the ACL assigned to an object requires BROWSE permission and Change Permissionextended permission on the object.
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.
Once upon a time there were ACLs (Access Control Lists) in Documentum. All the internal artifacts used the term. Then they were renamed to permission sets, though internal references continued to use ACL as expected. So both the terms were prevalent.
In version 6.5 the Content Server Fundamentals guide doesn’t even mention the term permission set. It seems to be all ACL again. But wait, Composer uses permission sets liberally.
Does it really matter? Probably not. Then why mess with the terminology repeatedly? I am sure that there are better ways to improve the platform.
Object permissions are stored as integers in Documentum ACL objects. For each accessor, there is one value (1-7) which represents one of None, Browse, Read, Relate, Version, Write, and Delete. These permissions are hierarchical, so 4 would imply 4 and everything below it.
ACL’s also include extended permissions. An accessor can be assigned a subset of Change Location, Change Ownership, Change Permission, Execute Procedure, Change State, and Extended Delete. All of these values are independent and they can be assigned in any combination to one accessor in an ACL. However, there is only one field to store the extended permissions for one accessor. The obvious way to store such information is using bit fields and, indeed, that is how it is stored in the repository. There is only one catch though – the details are hard to find until you hit the DFC Javadocs for IDfACL. There you can find the specs under the method getAccessorXPermit().
You would think that that’s the whole story but it isn’t. It’s very easy to get it wrong like this post did. The bits at position 0 and 1 are interpreted in a reverse manner compared to the rest of the bits – 0 means has permission and 1 means doesn’t. That is why “no extended permissions” is encoded as 3!
That’s about it. The only additional piece is that D6 has added a new extended permission – Change Folder Links. The Javadoc for bit-encoding hasn’t been updated to reflect this change. However, it will be pretty easy to figure out by dumping an ACL object containing that extended permission.
[UPDATE] Here is the obvious way to implement it using the bit-wise AND operator (&). // assuming that R_ACCESSOR_XPERMIT contains the integer value to be decoded
boolean execProc = (R_ACCESSOR_XPERMIT & 1) == 0;
boolean chgLoc = (R_ACCESSOR_XPERMIT & 2) == 0;
boolean chgState = (R_ACCESSOR_XPERMIT & 65536) != 0;
boolean chgPerm = (R_ACCESSOR_XPERMIT & 131072) != 0;
boolean chgOwner = (R_ACCESSOR_XPERMIT & 262144) != 0;
boolean extDelete = (R_ACCESSOR_XPERMIT & 524288) != 0;
And just for fun, here is another way to implement this decoding without using bit-wise operations. The % is the mod operator which takes the remainder after division. // assuming that R_ACCESSOR_XPERMIT contains the integer value to be decoded
boolean execProc = (R_ACCESSOR_XPERMIT%2) == 0;
boolean chgLoc = (R_ACCESSOR_XPERMIT%4) - (R_ACCESSOR_XPERMIT%2) == 0;
boolean chgState = (R_ACCESSOR_XPERMIT%131072) - (R_ACCESSOR_XPERMIT%65536) != 0;
boolean chgPerm = (R_ACCESSOR_XPERMIT%262144) - (R_ACCESSOR_XPERMIT%131072) != 0;
boolean chgOwner = (R_ACCESSOR_XPERMIT%524288) - (R_ACCESSOR_XPERMIT%262144) != 0;
boolean extDelete = (R_ACCESSOR_XPERMIT%1048576) - (R_ACCESSOR_XPERMIT%524288) != 0;