Features

Security

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

Permissions

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.

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.