Security

Plastic SCM includes a complete security system, achieving these two goals:

• To provide precise control over many SCM operations, both at the data level (entire codebase, subtree, individual file) and at the metadata level (repository, branch, baseline, etc.)
• To enforce SCM policies and best practices, without needing to resort to triggers. Example: allow only members of the Integrators group to make changes on the mainline, so that developers can never break the build.

Access control lists (ACLs)

The security system is based on access control lists (ACLs). Every repository object has a set of permissions, each of which grants or denies a particular user or group the right to perform a particular operation on that object.

This figure depicts the ACL for a repository's main branch:

Permissions are defined for a wide set of SCM operations, as shown below. This makes it easy to implement fine-tuned development policies.

Setting an object's ACL

As with all Plastic SCM operations, setting an object's ACL is a simple point-and-click process:

You can also check and set permissions from the command line, with the "cm acl" command.

Security hierarchies and permission inheritance

You might assume that to achieve precise control over the development environment, you need to set many individual permissions on many individual objects. But Plastic SCM's permission-inheritance scheme makes that unnecessary. Each permission on an object can be inherited two ways: the file system hierarchy (directory, subdirectories, files) and the repository object hierarchy, shown here:

The Advanced pane of the Permissions window enables you manage the inheritance of permissions through these hierarchies.