ACL

---

Description

Sets permissions on an object.

Usage

cm acl (--user=<usr_name> | --group=<group_name>) (-allowed|-denied|-overrideallowed|-overridedenied=+|-<permission>[,...])[,...] <objectspec>

Options

Special usage for secured paths

cm acl [(--user=<usr_name> | --group=<group_name>) (-allowed|-denied|-overrideallowed|-overridedenied=+|-<permission>[,...])[,...]] [--delete] [--branches=[+ | -]<branch>[,...]] <spec>

Help

Configuring permissions requires understanding how UVCS security works. Check the Security Guide to learn how permissions work.

Remarks

This command sets permissions for a user or group on the specified objects, repositories, branches, labels and/or server paths. Object specs: (Use 'cm help objectspec' to learn how to specify objects.) The 'acl' command uses a special type of spec: secured paths. Secured paths specs: path:server_path[#tag] Examples:

• path:/src/foo.c
• path:/doc/pdf
• path:/doc/pdf#documents

Permission action: Use -allowed and -denied to specify what permissions to set. Use -overrideallowed and -overridedenied arguments to specify what permissions to override. Each action requires a permission list separated by commas. Permission names: Each permission name is preceded by + or - symbol. The + symbol sets the permission and the - symbol clears it. To see the permissions of an object, use the 'cm showacl' command. Overridden permissions: Overriding a permission using -overrideallowed and -overridedenied allows you to bypass inheritance. It is helpful to bypass permissions set at the repository or server level. Example:

cm acl --user=vio -allowed=+ci -overrideallowed=+ci br:qa@test

(Allows user 'vio' to checkin on the branch 'qa' on repo 'test' even if she has the permission denied at the repo level.)

Server path permissions (a.k.a. secured paths)

• It is possible to specify permissions for a given server path.
• These permissions are checked during the checkin operation.
• These permissions can also be checked during the update operation, and can be used as a way to prevent certain directories and files to be downloaded to the workspace.
• For every item to checkin, the server tries to match the item path with a secured path. If it matches, the checkin operation checks whether the item has permissions to be checked in.

The permissions that can be defined for a secured path are the following: 'ci', 'change', 'add', 'move', 'rm', 'read' If the permissions check is not successful for any of the involved items, the checkin operation will be rolled back. To set secured path permissions to a group of branches, use the --branches option. Example:

cm acl --user=jo -denied=+ci path:/src#rule0 --branches=main,main/rel0

To edit the ACL associated to the secured path, the tag is useful. Example:

cm acl --user=jo -denied=+rm path:/src#rule0

(Without the tag, the list of branches would need to be specified again.) The list of branches of the secured path can be edited. Example:

cm acl path:/src#rule0 --branches=-main,+main/rel1

(Removes 'main' from the list and adds 'main/rel1'.) To remove a secured path, use the --delete argument. Example:

cm acl --user=jo --delete path:/src#rule0

Inheritance: Inheritance is an option that comes from the days of Plastic SCM 3.0. It is advanced, but almost deprecated. It lets an object inherit its permissions from any other object, overriding the default inheritance relationships. Use the option -cut to cut the inheritance chain. Use the option -cutncpy to cut and copy the current inherited permissions. (This is inspired on the Windows filesystem permissions where you can cut inheritance but retain the actual permissions.) The -inherit option allows the user to inherit from an object spec. Example: '-inherit=object_spec'

Examples

cm acl --user=danipen -denied=+ci rep:core

(Denies checkin for user 'danipen' on repo 'core'.)

cm acl --group=developers -allowed=+view,-read -denied=+chgperm br:main

(The command grants view permission, clears read permission, and denies chgperm permission to 'developers' group in 'main' branch.)

Secured path examples

cm acl --group=devs -denied=+ci path:/server#rel --branches=main,main/2.0

(The command denies the checkin permission to 'devs' group for any path that matches '/server' in the branches 'main' and 'main/2.0'. The tag '#rel' is created to be able to refer to it later.)

cm acl path:/server#rel --branches=-/main,+/main/Rel2.1

(Updates the secured path '/server' whose tag is 'rel', removing the 'main' branch and adding the branch 'main/Rel2.1' to the branch group the secured path applies to. Considering the previous example, now the branches list will contain 'main/Rel2.1' and 'main/2.0'.)

cm acl --user=vsanchezm -allowed=-read -overrideallowed=+read path:/doc

(Removes 'read' permission to 'vsanchezm' overriding it in '/doc' path.)