The Plastic SCM security system is designed with the following goals in mind:
- Provide a mechanism to control access to repositories and restrict certain operations. Many companies mandate the assignment of different permissions to different projects, users and groups to efficiently restrict access and prevent sensitive data from being read or modified by unauthorized personnel.
- Enforce policies and best practices for both development and deployment. Sometimes it is not about restricting access (think about small agile teams where trust is everything) but about enforcing best practices and prevent mistakes. This is the main reason why many development groups restrict access to the main development line (the br:/main branch in Plastic parlance) so that only integrators can make modifications to it.
In Plastic, every object has an associated Access Control List (ACL) making it very simple to customize access and overall security.
This guide aims to explain how the Plastic SCM security system works by going through practical case studies and examples.
The first step to securing your Plastic SCM server is to close any open doors. By default, Plastic SCM gets installed with all the open doors. By default, when Plastic SCM is first installed, the default security setup is to leave all entirely open. This means that any user authenticated by the system will be granted full access.
Since only recognized users can log in by default, when a non-authenticated user tries to connect to the Plastic SCM server, an error message is displayed like the example below:
And it's because mike is not authenticated in the Plastic SCM server:
But, as we've said before, by default, any other authenticated user can do almost everything because the ALL USERS group is the owner of the repositories server (repserver):
If your environment requires security restrictions, whether they are to prevent unwanted access or enforce certain development policies, you should consider the following helpful hints:
- Consider changing the permissions to the repository server as the first step in setting up a security policy. Changing the permissions to the top-level element in the security hierarchy will ensure that all the rest of the objects get secured.
- Define which users and groups will have access to the Plastic SCM server and then give them the right level of access to the repository server. Later on, you can customize specific privileges to repositories, branches, and even items, if required.
These general rules can be implemented by doing the following steps:
- Set up an administrator user and grant it full access.
- Remove the ALL USERS group from the top of the hierarchy.
- Carefully define the users and groups and their permissions.
Refer to the following chapters to get all the information you will need to secure Plastic SCM.
Note: You must clearly understand the meaning of each of the available permissions and their impact on the system by carefully reading this guide.
To configure the permissions on a Plastic server, there must be at least one existing repository.
This way, you can open the permissions configuration panel.
As we have seen previously, to start securing the Plastic SCM repositories server (repserver) you must set up an administrator user who will be the owner of the repserver. To do that, open the Permissions for the repserver window from the Repositories view in the Plastic SCM GUI:
Note: If you are working in the User/password authentication mode, you must first create the users that will work with the Plastic SCM system. Use the Plastic SCM User management server tool to execute this task.
In the Permissions for the repserver window you'll see that the group ALL USERS is the owner of the repositories server by default. What we need is to set up a repserver administrator user and remove that group. So click the Change button, and in the new window search for the user you want to be the administrator user and click OK:
By selecting maria as the repserver administrator, she has now become the owner:
But since the group ALL USERS still has all the permissions granted, all users will inherit all of these permissions by default, so it is necessary to remove the ALL USERS group. Before you can remove the ALL USERS group, a user or group must be added, and all the permissions must be granted.
To do that, click the Add button and select a user or group. We're going to designate the user maria as the owner and administrator:
Click OK, and all permissions will automatically be granted to the user maria. You can now remove the group ALL USERS, and maria will remain as the only authenticated user in the Plastic SCM system:
Click OK to save this change and close the window.
It is possible to restrict read access to certain paths to make some repository parts not visible to certain users. It is useful in centralized setups where sensitive areas of the project must be protected in such a way that some project members can't even see them.
The minimum version required for both Plastic SCM Client and Server must be 220.127.116.110.
It is recommended that you configure the path-based security to protect read access before using the repository for the first time. Otherwise, the admins must consider that the users will have to run update operations (without local changes) to propagate the new read permission rules to their workspaces and avoid further issues with the fast-update, merge, and update-merge operations.
By restricting the read access to certain paths, it is possible to have some situations in which we could have incomplete changesets. The incomplete changesets are important when working in distributed scenarios.
In distributed scenarios, enable the following setting inside the
This setting will reject operations when the path permissions of a revision cannot be checked because its changeset was not replicated yet.
GitSync and GitServer ignore any path-based security.
Note about effective permissions: Remember that permissions on paths inherit from the branch and the repository permissions.
Root item - The read permission can be safely revoked from the root item. Any attempt to update or view the repository will result in receiving an empty items tree. However, we suggest you deny access to the whole repository instead.
Update-merge - The update-merge operation fails with checkouts (co/add/rm/mv) under a path where the user loses the read permission. This case is handled, and the following error is returned:
The merge cannot be done because some local changes cannot be processed. Most likely, you don't have the proper permissions to make changes in some of the paths involved. Check the server log for more information.
This happens when you download code to /src/project, and then later, the admin revokes access to this directory, but you already had checkouts inside.
The update-merge happens when you are on a branch, you have checkouts, you update to latest, and your checkouts are moved to latest using a merge under the hood.
How this read access restriction works with some Plastic operations:
Note: The Diff operation will show the secured paths, if the user has permissions to read the change in the destination changeset.
- Restrict read access to certain paths so that some parts of the repository are not visible to certain users.
- Security policy to enforce:
- When running diffs, mike won't be able to see the changes in the
/src/tools path because he doesn't have permission to read there.
- To enforce this security policy as an administrator:
- Create a secured path related to the
/src/tools path in the rep00 repository.
- Deny or remove the read permission to the user mike for that path.
- How to configure the security policy as an administrator:
- In the Repository view, launch the Path permissions dialog:
- Click the Add button to create a new secured path. In the new window, type or select the
/src/tools path and then click OK to save this new secured path:
- Once the secured path is created, then all the users and groups defined in the repserver will appear in the Users and groups list. You must indicate the specific users or groups that will not diff and see that path. Edit the permissions by denying the read operation:
- Maria will make some changes: One in the
/scr/tools path and another in the
- Then, Maria will save the changes (by doing checkin) and will run a diff:
- Check the configuration:
- If Mike runs a diff, he won't be able to see the changes in the
/src/tools path. The diff operation will filter out the differences. If the source of the diff can't be seen, the diff won't be visible:
You've learned how to create a secured path with permissions and how to assign it to users and groups. As you know, a secured path prevents users and/or groups from performing operations (change, read...) on this path.
A user could think about trying to "hack" this security rule. This way, they can get access or make changes to the secured path, for example. But we thought about it too, and we can avoid it.
Let's suppose that in the following scenario, the administrator:
- Created a secured path related to the
/src/tools path in the rep00 repository.
- Denied or removed the read permission to the user mike for that path.
The user tries to rename the parent directory
/src of the
/src/tools secured path because he thought he could see the content by changing the secured path name. But the following error message will be displayed:
The Plastic SCM security system detects that the permissions are different, and automatically this hacking is avoided.