Why do I have lots of ACLs in my docbase and how do I remove them?

Why do I have lots of ACLs in my docbase and how do I remove them?


If you believe that you have too many ACLs and they are causing the problem, please read this Support Note.

Background:
Internal ACL vs Named ACL:
- A named ACL is an ACL that was created by an administrator or a user in the docbase. The attribute owner_name of this ACL will show a user name. For example, owner_name: dmadmin
- Internal ACLs are automatically generated by the docbase, and they have a computer generated name, such as dm_. For example dm_4500123480000101


What are the implications of having too many ACLs?
A large number of ACLs in your docbase is difficult maintain. Also, having too many internal ACLs may reveal an incorrect set up: If your business process is correctly implemented and set up, there should be very few occasions when internal ACLs are being generated.


How are Internal ACLs created? ……………….
Every dm_sysobject object in the docbase has an ACL assigned to it. Depending on the ACL inheritance of the serverconfig object, you can set how new objects get their ACL.

There are 4 ways where you can set an ACL to a particular object:
1. user
If your serverconfig is set to use "user", then every time the user creates a new object, this object will get the same ACL values as the user's default ACL.

2. folder
In a "folder" mode, the object gets its ACL from the folder where it is created.

3. type
Using "type" mode, default ACL of the type is being used to set the values of the newly created object's ACL.

4. permission set templates
You can use permission set template to set the ACL of an object. The requirement for permission set template is that the Server needs to be able to resolve any alias sets that might be related to the Permission Set Template. See Documentum eContent Server Object Reference Manual version 4.2 under (Alias Scope) page 1-26.


How do I find out the number of ACLs in my docbase?
1. Total ACLs:
DQL> select count(*) as Total_Number_of_ACLs from dm_acl

2. For Named ACLs created by users or the system administrator, you can run:
DQL> select count(*) as Number_of_Named_ACLs from dm_acl where r_is_internal=0 and acl_class = 0

3. For Template ACLs, you can run:
DQL> select count(*) as Number_of_Template_ACLs from dm_acl where r_is_internal=0 and acl_class <> 0

4. For Internal ACLs, you can run:
DQL> select count(*) as Number_of_Internal_ACLs from dm_acl where r_is_internal=1 and acl_class = 0

5. For Internal ACLs created from Template ACLs, you can run:
DQL> select count(*) as Number_of_Internal_ACLs_From_Template from dm_acl where r_is_internal=1 and acl_class <> 0

You should have:
#1 = #2 + #3 + #4 + #5

There is a good chance that the number of Internal ACLs (query #4 above) is high and represents more than 95% of the total number of ACLs in the docbase (query #1). Those are the ACLs that we can get rid of. Also, once your docbase is properly set up, no new Internal ACLs should be created any more.

For more information on those topics, please refer to the eContent Server documentation.

***********### IMPORTANT ###***********
Before going further in the resolution, we assume that you understand:
- DQL queries
- ACL model in Docbase
***************************************


==[ Step A ]=============================
Find out which Default ACL Mode the Docbase is currently using, then identify the folders / type / users which are using an Internal ACl and change it to a Named ACL so that the docbase stops generating Internal ACLs.

A.1. First, run the following query to find out what Default ACL the docbase is using:
DQL> select default_acl as Default_ACL_Mode from dm_server_config where object_name=''

A.2. The result should be 1, 2 or 3 but regardless of the result, we suggest that you go through all the steps A.2.1, A.2.2 and A.2.3. The reason is that you want to remove all references to Internal ACls that folders or types or users may have.

A.2.1 If Default ACL mode is 1 (Folder):
Retrieve all the folder names which have an Internal ACL:
DQL> select r_object_id, acl_name, acl_domain, object_name from dm_folder where acl_name like 'dm_45%'

Update the ACLs of all folders that have Internal ACLs to your Named ACL.
DQL> update dm_folder objects set acl_name = '', set acl_domain = '' where acl_name like 'dm_45%'

Note: 'your docbase name' is the name of the docbase and 'your system ACL' is the name of a system ACL that you want to use as the default ACL. A system ACL is a Named ACL owned by the system administrator which can be shared across users.

Note: You need to update the acl_domain also if you want to update the acl of an object.

Note: We strongly recommend that you use a Named ACL that is owned by System. The reason is because you want to easily share this Named ACL with other users.


A.2.2 If Default ACL mode is 2 (Type):
Retrieve the default ACL and the owner name of the ACL for object types if the types have an Internal ACL associated with them:
DQL> select r_type_name, acl_name, acl_domain from dmi_type_info where acl_name like 'dm_45%' or acl_name = ' '

Update the ACLs of all types that using an Internal ACL or are don't have an ACL assigned and are subtypes of dm_sysobject by using Documentum Administrator interface. No DQL query is available for this task since dmi_type_info is an internal type.


A.2.3 - If Default ACL mode is 3 (User):
Retrieve all users (and groups) that are using an Internal ACL:
DQL> select r_object_id, user_name, acl_name from dm_user where acl_name like 'dm_45%'

Assign a named ACL to those users (and groups):
DQL> update dm_user objects set acl_name = '', set acl_domain = '' where acl_name like 'dm_45%'

Note: 'your docbase name' is the name of the docbase and 'your system ACL' is the name of a system ACL that you want to use as the default ACL. A system ACL is a Named ACL owned by the system administrator which can be shared across users.

Note: Make sure you update the acl_domain together with the acl_name. If the acl that you are assigning is not part of the current acl_domain, the server will return an error.

Note: We strongly recommend that you use a Named ACL that is owned by System acl_domain= rather than acl_domain=

The reason is because you want to easily share this Named ACL with other users and this is only possible if the ACL is owned by System.

===[ Step B ]=======================
At this point, you docbase should not generate new Internal ACLs. However, existing objects may be using an Internal ACL. This step helps you indentify those objects and change the Internal ACL to a Named ACL. This step is required before attempting to remove Internal ACLs.

B.1 - Retrieve all objects (content and folders) across the docbase that are using an Internal ACL:
DQL> select count(*) from dm_sysobject (all) where acl_name like 'dm_45%' and acl_name not like 'dm_45%\_8%' ESCAPE '\'

If you need to review those objects one by one:
DQL> select r_object_id, object_name, acl_name, acl_domain from dm_sysobject (all) where acl_name like 'dm_45%' and acl_name not like 'dm_45%\_8%' ESCAPE '\'

B.2 - Assign your Named ACL to all objects (content and folders) across the docbase that have Internal ACL:
DQL> update dm_sysobject (all) objects set acl_name='', set acl_domain='' where acl_name like 'dm_45%' and acl_name not like 'dm_45%\_8%' ESCAPE '\' and r_lock_owner is NULLSTRING

Note: 'your docbase name' is the name of the docbase and 'your system ACL' is the name of a system ACL that you want to use as the default ACL. A system ACL is a Named ACL owned by the system administrator which can be shared across users.

Note: Only the contents that are not checked out will be updated. You may want to run this query periodically until no contents get returned from the queries in B.1

Note: You can refine the query so that only a subset of those objects get a Named ACL - per folder or creation date for instance.

Note: Make sure you update the acl_domain together with the acl_name. If the acl that you are assigning is not part of the current acl_domain, the server will return an error.

Note: We strongly recommend that you use a Named ACL that is owned by System (acl_domain= rather than acl_domain=). The reason is because you want to easily share this Named ACL with other users and this is only possible if the ACL is owned by System.

Note: This query may take quite some time to run. In fact, the update statement may update so many objects at the same time that your database may run out of TEMP tablespace causing the query to fail. You may want to modify the query to modify a limited number of objects at the same time - by restricting per folder or creation date.

Note: You may not be able to update non-CURRENT objects if they are immutable. If this is your case, the query will return error DM_SYSOBJECT_E_CANT_SAVE_IMMUTABLE. In order to resolve this issue, you can take the '(all)' keyword out of the update statement so that only CURRENT objects will be updated. This may leave quite a significant number of Internal ACLs left in the docbase that are used by non-CURRENT objects.


===[ Step C ]===============================
Now that no new Internal ACL is created and most of the objects in the docbase are assigned a Named ACL - the remaining Internal Acls are those created from Template ACLs. Your docbase is now hosting many orphan ACLs. It is time to clean them up!

Job dm_clean can delete orphan ACLs from the docbase. While running job dm_clean (from Documentum Administrator or you can schedule the job to run periodically), make sure that argument '-clean_acl' is set to TRUE.

Before running the job, you can find out how many ACL the job will clean after going through step A and B:
DQL> select count(*) as Number_of_Internal_ACLs from dm_acl where r_is_internal=1 and acl_class = 0

To get more details about those ACLs:
DQL> select * from dm_acl where r_is_internal=1 and acl_class = 0

If you agree with the result, run dm_clean and go to Step D.

For more information, Refer to Documentum eContent Server Administrator's Guide Chapter 10 "Removing Unreferenced Internal ACLs".


===[ Step D ]===========================
Restart the docbase. Active sessions may still be running with no default ACLs and will keep generating internal ACLs.

After running dm_clean and restarting the docbase, you can verify if all Internal ACLs are gone by re-running the same queries as in Step C:
DQL> select count(*) as Number_of_Internal_ACLs from dm_acl where r_is_internal=1 and acl_class = 0

To get more details about those ACLs:
DQL> select * from dm_acl where r_is_internal=1 and acl_class = 0

You can identify the remaining documents that are still using a Internal ACL:
DQL> select r_object_id, object_name, title, acl_name, owner_name, r_version_label from dm_sysobject (all) where acl_name in (select object_name from dm_acl where object_name like 'dm_45%' and object_name not like 'dm_45%\_8%' ESCAPE '\') order by 1

For more information on how ACL are assigned in WebPublisher, please refer to Support Note 15997