Inherit from WHO?

The “Inherit from” server config setting is sometimes misunderstood or not even known. This security setting defines the default acl that will be assigned a newly created object that do not have an acl explicitly assigned to it. There are three options available for this setting: folder, type, and user. The default setting – inherit from user – will assign the acl defined in default_acl attribute for dm_user object to newly created objects. Since this setting works most of the time, most developers and administrators are not aware of this security mechanism.

The other two options are:

  • Inherit from type – document gets acl that corresponds to default acl assigned to the object type definition
  • Inherit from folder – documents gets acl_name that corresponds to acl_name assigned to the parent folder

Why should you care about this setting?

By using inherit from user, you potentially give the user the ability to grant/revoke permissions on individual documents. This leads to creation of unique acl for every document in the repository. The more acls that are created, the longer it takes for server to look up an acl to validate against. It is not uncommon for systems who have inherit from user to have 100,000s acls.

Inherit from type based is better than user, in that it is more likely to map to real world scenarios and the number of acls = number of types. For example, only accounting dept should have permissions on financial document. The problem with using this setting is that you have define a default acl for every sysobject object type in the repository (beyond just your custom types). The simplicity of this setting also makes it not very flexible. If you want to aggregate permissions for accounting dept, you would have to create more object types.

Inherit from folder mimics the typical permission inheritance that are used in most file systems. This setting is better than type, but requires management of acls at the folder level. The implication of this is that a user has to be careful where he/she imports a document.

In my experience, the best solution is to use TBOs (Type-based Business Objects) in conjunction with inherit from folder setting. TBOs allow you to explicitly define business rules on which acls to assign to which object types. Inherit from folder setting will allow you to persist the security on folder objects without the need to create a folder TBO.


11 responses to “Inherit from WHO?

  1. Hi Johnny,

    After havng read your post, I choose to change my server config to “Inherit from type” and assigned particular acl to each and every types I had created.

    However it seems that using this setting, I also need to define acl to “system” types, dm_user for example.

    Indeed I now get error when creating a new user:

    Error committing changes
    [DM_SYSOBJECT_E_TYPE_DEF_ACL]error: “ACL inheritance failed, due to missing ACL in the type ‘dm_cabinet’.

    Note that this error does not prevent the creation of the user but scares the hell out of me! 😉

    What does it means? When using this “inherit from type” settings, are “system” types really need to be updated with a default acls? Is there a workaroud (to assign a default acl to sm_sysobject for example)?


  2. Hi kmbcaribou,
    If you read my post carefully, I have already stated this: “…you have to define a default acl for EVERY sysobject object type…”

    The error you getting is cause by default behavior of DA. When creating a user, DA will automatically set the default_folder to be the user name. If you dont change this, DA will try to create a cabinet with the user name as the object name. Hence, the creation of the user object triggers the creation of cabinet object -> you get your error.

    There is no workaround for the Inherit From Type setting; you need to assign a acl for every dm_sysobject type. Using this setting, the content server looks for the default_acl value for the object type when creating instances of that object type. It does not have any kind of “fall back rules”. This setting is probably the least flexible of the settings.

    In about 80-90% of my projects, I use Inherit From Folder and write a TBO to set the permissions of documents based on attribute values. I have never used Inherit From Type.

  3. Thanks Johnny,

    Only a Guru could provide such a detailed answer (in just a few minutes;) It would have taking me days to figure out the link between the dm_user and the dm_cabinet.

    I might indeed consider going back to an “inherit from folder” solution.

    BTW if you happen to have any hint about a good resources explaining how to use TBO to assign permission UPON CREATION of a new dm_document object (method to override, etc.) I am much interested.

    Last time I tried to write a TBO to apply automatically a lifecyle to a newly created (imported) object, I ran into a lot of problems.

    Any any cases, thanks again for this hint about dm_cabinet.



  4. Hi Phillippe,
    Have you visited the EMC Developer Site ( It has a bunch of code samples, including various TBOs. You should be able to use them as a starting point. Good luck.

  5. Hi Johnnygee(Documentum Guru),

    This is Terrific discussion.

    How to set the default ACL for every type in the repository?

  6. You can use DQL to ALTER TYPE for each object type and set default ACL for each.

  7. Hi JOhnny,

    Could you provide sample DQL statement.

  8. If you want product support, I suggest you submit your question to EMC Support Forums. My blog is for design questions/issues.

  9. Hi Johnny,

    Please tell me where I have to post my blogs related to design in Documentum Guru(Your)’s bolg?

  10. Hi,

    I got a question. How come when I MOVE a file or folder to another destination it doesn’t inherit the ACL of the destination

    lets say I have /folderA/subfloderA/document.txt and the acl is sample_acl

    i will MOVE the document.txt to /folderB/subfolderB with acl as training_acl how come the document.txt still carry the sample_acl. it does not inherit the acl of folderB

    • Inherit Permissions Setting is ONLY executed when a object is first created. If you want to change the ACL as part of a move, then you will need to create a TBO.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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