Securing a Plastic SCM system
The two main motivations behind the Plastic SCM security system are:
After installing Plastic SCM, you can check that any authenticated user of the system will have full access granted.
The first step should be to assign a specific user (or group) as the repository server owner, and then, you can start defining your custom security restrictions. The repository server owner will be the “root” Plastic server user.
After that, it doesn´t matter if you, for some reason, misconfigure any permission because this user will be able to restore them again.
Whether they are to prevent unwanted access or enforce certain development policies, you should consider the following:
ACL´s and Permission inheritance:
Each user (SEcured IDentifier or SEID in Plastic terms) or group who has granted or denied permissions will have an entry in a given ACL. Each entry, will have allowed and denied permissions.
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 group of permissions at the server level that will apply to all the inheriting objects: repositories, branches...
Disable or deny permission ?
This is a question that you will probably need to answer when defining your permission policies. You need to take in account that disabling a permission is not the same as denying a permission.
Consider the following example; a certain user is a member of the “developers” group and at the same time of the “integrators” group. Developers are not allowed to commit at the “main” branch but integrator certainly are.
If we actively deny the checkin permission to the “developers” group on the main branch, this specific user won´t be allowed to perform the operation. The permission is granted due to he is an integrator but it’s denied because he is also a developer, the denied permission prevails over the granted.
On the contrary, if we disable the permission (but not deny it) to the “developers” group, he will be allowed to perform the checkin operation at the main branch because he also belongs to the “integrators” group, and combining a disabled permission with an allowed one results in an allowed permission.
After this brief introduction to the Plastic SCM permissions system, I would like to review some examples that may help you to implement different permission policies based on your organizational needs.
Case 1: Restrict permissions for integration branches
Imagine you are developing your project using a branch per task branching pattern. Developers create task branches to perform their work.
There are two different groups of people involved in the development: integrators and developers (but certain developers can act as integrators too).
The recommended workflow is the following: developers can’t "checkin","applylabel" or "rmchangeset" on the integration branches, and only integrators can perform these operations.
To handle this scenario, the proposed permissions configuration is:
Disable the "checkin", "applylabel" and "rmchangeset" permissions to developers (not deny but disable). Integrators will have these permissions allowed, but the developers won´t be able to execute the mentioned operations.
Remember that a user belonging to both groups will have the operations allowed: combining a disabled permission with an allowed one result in an allowed permission, meanwhile the users belonging only to “developers” won’t be able to perform the operations.
Case 2: Restrict access to branches:
In this second scenario, we have a development team that has the following roles: a system administrator group, a development group and an integration group.
If a user belongs to several groups, he will have all the combined benefits (if a user is both a developer and administrator, he should be given full access).
Steps to set up the scenario:
Case 3: Restrict access to directories:
In this case study, we have two different user profiles working on a branch: developers and artists. And we want to restrict the access to specific directories per user profile.
A possible solution for this scenario could be:
Note: If you need to completely hide the directory to a user, the best solution would be to create a new repository per user profile using Xlinks and then customize the "view" permissions per repository.
We have reviewed the main Plastic SCM features to secure a server and also some classic scenarios where you can customize the rules depending on your requirements.
What are the permission policies that you are using in your company? Could you share your configuration with us?