What is a System ACL vs. a User ACL?

A System ACL is an ACL that is created by a system administrator and is available for all users to use. The only thing that makes it a “system” ACL is that the owner of the ACL is the same as the docbase owner. Most ACLs in a docbase should be System ACLs.

A User ACL is an ACL that is owned by a user in the docbase. It can only be used by that user. Bob can not create a document and set its permissions to one of Fred’s User ACLs. Bob can only use his own User ACLs or a System ACL

Using the API Create an ACL

You create an ACL just like you create any other object, using the create, set, and save APIs. However, since the r_accessor_name and r_accessor_permit attributes are read_only, you can not set them directly. You must use the grant and revoke APIs. Below is the syntax for creating an example System ACL called World Write that lets all users have write access to the document, the owner have delete access, and members of a group named “system_admins” have delete access. Note that we are using the alias “dm_dbo” to represent the docbase owner.

create,c,dm_acl

set,c,l,object_name    World Write

set,c,l,owner_name dm_dbo

set,c,l,description All Users have Write Access

grant,c,l,dm_world,6 

grant,c,l,dm_owner,7

grant,c,l,system_admins,7

save,c,l

How do I Tell a Document Which ACL to Use?

To do this, you only need to set two attributes of the document, acl_name and acl_domain. The acl_name attribute is the name of the ACL you wish to use, and the acl_domain is the owner of the ACL you wish to use. You have to specify the acl_domain because different users might have created User ACLs with the same name.

Note: If you are using a System ACL, set the acl_domain to dm_dbo, Documentum’s internal alias for the current docbase owner.

How does a Document Get its Default ACL?

When you create or import a new document, if you don’t explicitly assign an ACL to it, Documentum will assign an ACL by default. But how does the server know which ACL to assign? Actually, you can configure the server to choose the default ACL based on one of three methods.

• By User: Every document created by a lawyer gets the legal ACL, regardless of what type of document it is or where it’s located. Every user has a default ACL defined in the dm_user object. You can see this by going to the Users dialog in Workspace. If you configure the docbase to assign default ACLs by user, the ACL that is assigned to a new document will be determined by the ACL that is defined in your dm_user object. The default Documentum installation will assign default ACLs based on the user’s default ACL.
• By Object Type: Every contract gets the legal ACL regardless of who created it or where it is located. If you configure Documentum to assign default ACLs based on object type, then whenever an object is created, it will get the ACL that is assigned to the object type that you are creating. If no ACL has been assigned to the object type, the server will traverse up the object hierarchy until it finds an object type that does have an associated ACL.
• By Folder: Every document created in a folder gets that folder’s ACL regardless of the type of document or who created it. This is probably the most meaningful way to assign default ACLs. Whatever ACL is assigned to the folder that the document is created in, this is the ACL that will be assigned to the document.

To configure the server to use one of these methods, set the default_acl attribute of the dm_server_config object. Use 1 to assign default ACLs based on Folder, 2 to assign based on Object Type, and 3 to assign based on User.

What is an Internal ACL?

An internal ACL is an ACL created on-the-fly by the server, rather than being created explicitly by a user or system administrator. An internal ACL is easy to spot because of its name; Internal ACLs are named dm_<object_id> (dm_4500225180000108).

Internal ACLs are created by the server when necessary and cleaned up by the server when they are no longer needed. They are created when you use the grant and revoke APIs to modify the permissions of a document directly.

Determining a User’s Access Level to a Document

Sometimes you need to check to see if a user has a certain access level to a document. For example, you might want to ensure that a user has delete a\cess to a document before you let them delete it, otherwise they might get an ugly error message from the server.

There is a special computed attribute, _permit, on every sysobject that can tell you what your permission level is for that document. This attribute is computed for you anytime you fetch a document, and the value is different for different users (obviously). The value can be anywhere from 1 to 7, corresponding to the NONE to DELETE levels of access. Unfortunately, since the object must be fetched in order for _permit to be computed, you can not query the docbase for this attribute.

Categories of ACLs

ACLs are either external or internal ACLs. They are also further categorized as public

or private.

External ACLs are ACLs created explicitly by users. The name of an external ACL

is determined by the user. External ACLs are managed by users, either the user who

creates them or superusers.

Internal ACLs are created by Content Server. Internal ACLs are created in a variety of

situations. For example, if a user creates a document and grants access to the document to HenryJ, Content Server assigns an internal ACL to the document. (The internal ACL is derived from the default ACL with the addition of the permission granted to HenryJ.) The

names of internal ACL begin with dm_. Internal ACLs are managed by Content Server.

The external and internal ACLs are further characterized as public or private ACLs.

Public ACLs are available for use by any user in the respository. Public ACLs created

by the repository owner are called system ACLs. System ACLs can only be managed

by the repository owner. Other public ACLs can be managed by their owners or a user

with Sysadmin or Superuser privileges.

Private ACLs are created and owned by a user other than the repository owner.

However, unlike public ACLs, private ACLs are available for use only by their owners,

and only their owners or a superuser can manage them.

documentum-security-access-control-lists.zip