Decoding xperms

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;

Advertisements

One thought on “Decoding xperms

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s