All objects in Plastic SCM can be secured using a fine grained mechanism based on Access Control Lists (ACL).

Administrators can set permissions to repositories, branches, labels and so on in order to restrict certain operations and enforce organization-wide policies and best practices.

User and Groups

User and group identification is tightly related to security although Plastic SCM handles it as different layers: on one hand the permissions to set to objects and assigned to certain “user identifiers” and by the other hand the users and groups where the “user and group ids” come from.

This way “user identification” is achieved using one of the following mechanisms:

1 LDAP and Active Directory integration:

Users and groups are retrieved from an existing LDAP or Active Directory. Find more here.
It can be seamlessly configured to work on Windows, Linux and Mac OS X.

2 User/Password based identification:

The Plastic SCM server will handle users and groups with a file based mechanism (users.conf and groups.conf files). This alternative is very useful for departments who can’t rely on the corporate security setup, small teams and also for distributed developers working disconnected from the main site.

3 Name and Name+ID identification:

Designed with testing and evaluation in mind the “name” modes rely on the user and group names existing on both the client and server. If the names match then the user is correctly identified. This mechanism is not secure unless the underlying network is totally secured and hence it is not recommended for production.

Access Control Lists (ACLs)

Each repository, branch, label, attribute, trigger and even server can have an associated ACL in Plastic SCM.

Each ACL can have several entries, each of them associating to a user or group a set of granted or denied permissions.

The following picture illustrates how an ACL associated to the “main” branch looks like based on the previous definition:

Access Control Lists (ACLs) illustration


Server specific permissions

There are certain permissions that can be applied to the server to control certain operations:

mkrepository Controls the ability to create a new repository. Applies at the server level only.
rmrepository Controls the ability to delete repositories. It applies both at the server level and at the repository level (whether an specific repository can be deleted or not).
Server specific permissions
rmrepository Whether the repository can be deleted or not.
mktop-levelbranch Controls whether top level branches can be created (branches like “main”).
mklabel Controls whether labels can be created on the repository (there is another permission “apply label” related to this one).
mkattr Controls whether attributes can be created.
mktrigger Controls whether triggers can be created.
advancedquery It is an special permission controlling who can run advanced queries (cm query command, issuing plain SQL queries towards the database schema). By default it is not granted to anyone.
Object Permissions

Permissions that can apply to several objects inside the repository.

chgperm Permission to “change permissions”. Applies to all objects.
chgowner Permission to change the owner of an object.
view Permission to “view” an object. Applies to branches, labels and attributes.
read Permission to retrieve information from the object (read it). Applies to branches, labels and attributes.
rename Permission to rename repositories, branches, labels and attributes. Note: for files and directories check the “move” permission.
changecomment Permission to change a comment to a branch, label and attribute. * rmchangeset – permission to delete a changeset, applies to branches.
rmlabel Permission to delete a label, applies to labels.
rmtrigger Permission to delete a trigger, applies to the trigger itself.
rmattr Permission to remove an attribute, it applies to the attribute itself.
mkchildbranch Permission to create a child branch of a given branch or label.
mergefrom Permission to run merges from branches or labels.
applylabel Permission to apply a label to branches and labels.
applyattr Permission to apply attributes.
File related permissions

While this permissions are applied to branches, they control whether specific file and directory operations can be applied.

These permissions were introduced in Plastic SCM 4.2.

They can also be applied to an special secured object called “secured path” which means users can define rules such as: “never let coders checkin under the /art/photoshop directory”.

The list of permissions is:

add Controls whether files and directories can be added or not.
change Controls whether files and directories can be modified (for instance you can allow someone to perform “moves” or “deletes” but not modify existing files).
move Whether elements can be moved or renamed.
rm Whether elements can be deleted.
ci General checkin permission, controls the whole checkin operation.
Replication permissions

They are useful to control replication operations:

replicateread Allows or denies to read a certain branch to be replicated. If the branch doesn’t have the permission it can’t be replicated.
replicatewrite Controls whether a branch can be written during replication operations.

Permission inheritance

Permissions in Plastic SCM are inherited from the top object in the hierarchy (the server) down to the lower ones.

This way it is very simple to set a permission at the server level that will apply to all repositories or at the repo level for all branches and so on.

Permissions big icon

Setting permissions

Plastic SCM, screenshot of settings permissions window

Permissions can be set from the GUI or from the CLI using the cm acl command.

Get the latest news