ACL vs permission set

There is one object type. Documentum Administrator says permission set. DFC, DQL, and the object model say ACL (dm_acl). Same repeating accessors, same integers. See permits 1–7.

Names you will see

• ACL / permission set — dm_acl. Identified by object_name + owner_name (the domain).
• Permission set template — an ACL with ACL class template (class 1). Instances (class 2) are copies bound to an alias set; regular ACLs are class 0.
• On a SysObject: acl_name + acl_domain point at that ACL. Domain is the ACL owner, often dm_dbo for system ACLs.

select object_name, owner_name, acl_name, acl_domain
from dm_sysobject
where r_object_id = '09xxxxxxx'

select r_object_id, object_name, owner_name, acl_class
from dm_acl
where object_name = 'my_acl'
and owner_name = 'dmadmin'

dm_owner and dm_world

Two accessor names that are not real users:

• dm_owner — whoever owner_name is on the SysObject at evaluation time. Change the owner, this row follows.
• dm_world — every user in the repository. The usual “everyone else” grant (often Browse or Read on public cabinets).

Resolved permit for a session is the most permissive applicable row (user, groups, owner alias, world), subject to restrictions / required groups if those TCS entries exist.

Default ACL when you create an object

A new SysObject does not invent an ACL from nowhere. Content Server picks a default from repository configuration, typically one of:

• the folder you link into (the folder’s own ACL),
• the object type (default ACL on the type),
• the user (the creator’s default ACL).

Which source wins is a docbase setting, not a per-object checkbox. After create, the object has its own acl_name / acl_domain; changing the folder’s ACL later does not rewrite existing objects unless something in your app does that on purpose.

Internal ACLs (server-created, IDfACL.isInternal()) show up when someone grants directly on an object instead of assigning a named permission set. Prefer named ACLs you can query and reuse.

Cabinets, folders, inheritance

Cabinets (dm_cabinet) are the top of the folder tree. They are folders with extra constraints (a cabinet is not placed inside another cabinet). Both cabinets and folders are SysObjects and have ACLs.

Two different ideas get called “inheritance”:

1. Default ACL at create — if the docbase uses folder defaults, a document created in /Claims/2026 starts with that folder’s permission set. Move it later and the ACL does not automatically become the destination folder’s ACL.
2. Folder security — a repository option. Even with Read on the document, the user also needs enough permit on the folders in the path to navigate there. Browse on the folder is the usual requirement to see contents in a path. Object-level ACL and folder-level ACL are evaluated together; one does not replace the other.

An object may be linked to several folders (i_folder_id repeating). Primary folder vs extra links matters for some clients; the ACL on the object is still one ACL, not a merge of every parent folder.

Practical habits

• Name ACLs on purpose. Query acl_name / acl_domain in dumps and job reports.
• Put groups on the ACL, not hundreds of user rows.
• Use dm_world deliberately. None (1) on a named group is how you hide an object from that group even if world would otherwise see it — test that combination; do not assume.
• Grant/revoke with DFC, not by poking dm_acl_r.

select r_object_id, object_name
from dm_sysobject
where acl_name = 'my_acl' and acl_domain = 'dmadmin'