documentum security, user privileges, object-level permissions
- User privileges
Basic user privileges
0 None User has no special privileges
1 Create Type User can create object types
2 Create Cabinet User can create cabinets
4 Create Group User can create groups
8 Sysadmin User has system administration privileges
16 Superuser User has Superuser privileges
The basic user privileges are additive, not hierarchical. For example, granting Create Group to a user does not give the user Create Cabinet or Create Type privileges. If you want a user to have both privileges, you must explicitly give them both privileges.
Typically, the majority of users in a repository have None as their privilege level. Some users, depending on their job function, will have one or more of the higher privileges. A
few users will have either Sysadmin or Superuser privileges.
User privileges do not override object‑level permissions when repository security is turned on. However, a superuser always has at least Read permission on any object and can change the object‑level permissions assigned to any object.
Applications and methods that are executed with Content Server as the server always have Superuser privileges.
Extended user privileges
8 Config Audit User can execute the methods to start and stop auditing.
16 Purge Audit User can remove audit trail entries from the repository.
32 View Audit User can view audit trail entries.
The extended user privileges are not hierarchical. For example, granting a user Purge
Audit privilege does not confer Config Audit privilege also.
Repository owners, Superusers, and users with the View Audit permission can view all audit trail entries. Other users in a repository can view only those audit trail entries that record information about objects other than ACLs, groups, and users.
Only repository owners and Superusers may grant and revoke extended user privileges, but they may not grant or revoke these privileges for themselves.
What object-level permissions are
Object‑level permissions are access permissions assigned to every SysObject (and SysObject subtype) in the repository. They are defined as entries in ACL objects. The entries in the ACL identify users and groups and define their object‑level permissions to the object with which the ACL is associated. Each SysObject (or SysObject subtype) object has an associated ACL. For most sysObject subtypes, the permissions control the access to the object. For dm_folder, however, the permissions are not used to control access unless folder security is enabled. In such cases, the permissions are used to control specific sorts of access, such as the ability to link a document to the folder.
There are two kinds of object‑level permissions: base permissions and extended permissions.
Base object-level permissions
| Level |
Permission Description |
| 1 |
None No access is permitted |
| 2 |
Browse The user can look at property values but not at associated content. |
| 3 |
Read The user can read content but not update. |
| 4 |
Relate The user can attach an annotation to the object. |
| 5 |
Version The user can version the object, but cannot overwrite the existing version. |
| 6 |
Write The user can write and update the object. Write permission confers the ability to overwrite the existing version. |
| 7 |
Delete The user can delete the object. |
These permissions are hierarchical. For example, a user with Version permission also has the access accompanying Read and Browse permissions. Or, a user with Write permission also has the access accompanying Version permission.
Extended object-level permissions
| Change Location |
In conjunction with the appropriate base permission level, allows the user to move an object from one folder to another. All users having at least Browse permission on an object are granted Change Location permission by default for that object. Note: Browse permission is not adequate to move an object. |
| Change Ownership |
The user can change the owner of the object. |
| Change Permission |
The user can change the basic permissions of the object. |
| Change State |
The user can change the document lifecycle state of the object. |
| Delete Object |
The user can delete the object. The delete object extended permission is not equivalent to the base Delete permission. Delete Object extended permission does not grant Browse, Read, Relate, Version, or Write permission. |
| Execute Procedure |
The user can run the external procedure associated with the object. All users having at least Browse permission on an object are granted Execute Procedure permission by default for that object. |
| Change Folder Links |
Allows a user to link an object to a folder or unlink an object from a folder. The permission must be defined in the ACL associated with the folder. |
The extended permissions are not hierarchical. You must assign each explicitly.
Default permissions
Object owners, because they have Delete permission on the objects they own by default, also have Change Location and Execute Procedure permissions on those objects also. By default, Superusers have Read permission and all extended permissions except Delete Object on any object.
Folder security
What folder security is
Folder security is a supplemental level of repository security. When folder security is turned on, for some operations the server checks and applies permissions defined in the ACL associated with the folder in which an object is stored or on the object’s primary folder. These checks are in addition to the standard object‑level permission checks associated with the object’s ACL. In new repositories, folder security is turned on by default.
Folder security does not prevent users from working with objects in a folder. It provides an extra layer of security for operations that involve linking or unlinking, such as creating a new object, moving an object, deleting an object, and copying an object.
ACL and object-level permissions
Each SysObject has an associated ACL(object-level permission)
SysObject (*) User(has acl_name attribute) (*)
has acl_name attribute grant to user, ACL.grant(accessor,permit,xpermit)
ACL is assigned to an sysobj an ACL can be granted to multi-accessors
ACL(1) (accessor_name,accessor_permit,accessor_xpermit,application_permit)
With grant operation, Users(assessors) associate with an ACL, so, the users have object-level permissions. The other way, each SysObject object has an ACL. Through the two steps, object-level permission is available when users access a SysObject object,
What an ACL is
ACL is the acronym for access control list. ACLs are the mechanism that Content Server uses to impose object‑level permissions on SysObjects. An ACL has one or more entries that identify a user or group and the object‑level permissions accorded that user or group by the ACL.
Each SysObject object has an ACL. The ACL assigned to most SysObjects is used to control access to the object. Folders are the exception to this. The ACLs assigned to folders are not used to defined access to the folder. Instead, they are used by folder security and may be used as default ACLs for objects stored in the folder.
Implementation overview
An ACL is represented in the repository as an object of type dm_acl. An ACL’s entries are recorded in repeating properties in the object. Each ACL is uniquely identified within the repository by its name and domain. (The domain represents the owner of the ACL.) When an ACL is assigned to an object, the object’s acl_name and acl_domain properties are set to the name and domain of the ACL.
After an ACL is assigned to an object, the ACL is not unchangeable. You can modify the
ACL itself or you can remove it and assign a different ACL to the object.
ACL is for object level permission, and RBAC is for operations control.
role, group, queue ? http://johnnygee.wordpress.com/page/14/
还是没太弄明白...