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:
LDAP and Active Directory integration:
Users and groups are retrieved from an existing LDAP or Active Directory.
It can be seamlessly configured to work on Windows, Linux and macOS.
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.
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:
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).
Repository 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
Permissions can be set from the GUI or from the CLI using the cm acl command.
