Plastic SCM Security guide


Motivation

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.


Secure the Plastic SCM server

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:

Invalid credentials

And it's because mike is not authenticated in the Plastic SCM server:

Plastic SCM server permissions - Users and Groups

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):

Plastic SCM server permissions

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:

  1. Set up an administrator user and grant it full access.
  2. Remove the ALL USERS group from the top of the hierarchy.
  3. 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.

Security scenarios


Important!

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.


How to set up an administrator user

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:

Repository server permissions

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:

Repository server permissions - Change owner

By selecting maria as the repserver administrator, she has now become the owner:

Repository server permissions - Changed 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:

Repository server permissions - Add 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:

Repository server permissions - Added administrator

Click OK to save this change and close the window.


Prevent accidental deletion of repositories by groups of users

Description:
A Plastic SCM user can delete a repository.
Security policy to enforce:
Any user belonging to the Consultants group will not be allowed to delete a repository.
To enforce this security policy as an administrator:
  • Add the group Consultants.
  • Deny the remove repository (rmrepository) permission to this group at the repserver level to prevent these users from deleting a repository.
How to configure the security policy as an administrator:
  1. Open the Permissions for repserver window:

    Repository server permissions

  2. Select the Consultants group and deny the remove repository (rmrepository) permission and click OK to save.

    Repository server permissions - Deny rmrepository

Check the configuration:
If any user in the Consultants group tries to delete a repository, the following error message will be displayed:

Repository server permissions - Deny rmrepository

To make sure groups cannot delete repositories:
  • Select the ALL USERS group.
  • Once added to the Users and groups list, select it and double-click the Allow All button to disable all the permissions but allow (enable) the view and read permissions.
  • To prevent any user from removing repositories, deny the rmrepository permission:
  • Repository server permissions - Deny rmrepository ALL USERS


Open up a repository to a specific group

Scenario:
A company has several projects in development. Each project is run by a development group that is specifically assigned a given repository.

Each repository is like a project that has certain functionalities implemented. So, at any given moment in time, a second development group may require read access to a repository not directly assigned to them. In this situation, the second development group considers the repository a subproduct (a dependency or a library) for their project.

Security policy to enforce:
Grant a development group read access to a repository that they are not directly assigned to:

Open up a repository

To enforce this security policy as an administrator:
  • Deny all the permissions to grp02 on the rep01.
  • Grant only read and view permissions to grp02 on the rep01.
How to configure the security policy as an administrator:
  1. Launch the Permissions window for the rep01 from the Repositories view:

    Repository permissions

  2. Add grp02. Then, click the Deny All button to deny every permission to grp02. And grant the read and view permissions:

    Repository permissions - Read and view

  3. Click OK to save this new group of permissions on the rep01 repository.
Check the configuration:
Now, every user belonging to the grp02 group will see (read) every item in the rep01 repository. But they can't perform any other operation such as renaming a branch, creating a label or removing a changeset.

Prevent users from modifying specific items

Scenario:
The Testers group consists of users that perform testing on code to find issues during the development cycle. Because their work is related to testing but not developing, they must have restricted access to the system source code.
Security policy to enforce:
Anyone in the Testers group in the rep00 repository will not be allowed to change anything inside the sys folder in the repository.
To enforce this security policy as an administrator:
  • Create a secured path related to the sys code folder in the rep00 repository.
  • Deny the check in (ci) permission to the Testers group on the new secured path.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Path permissions dialog:

    Path permissions

  2. Click the Add button to create a new secured path. In the new window, type or select the /src/sys folder, then click OK to save this new secured path:

    Path permissions - Secured path

  3. Once the secured path is created, all the users and groups defined in the repserver will appear in the Users and groups list. At this point, you must indicate the specific users or groups that will not make any change in that folder. To do this, click the Add button related to Users and groups and then select the Testers group. Click OK to add this group. Edit the permissions to the Testers group denying the check in (ci) operation. Click OK to save this permission:

    Path permissions - Secured path - Deny

Check the configuration:
If any user in the Testers group tries to execute a checkin operation on any item in the /src/sys folder, the following error message will be displayed:

Path permissions - Secured path - Deny


Prevent users from modifying specific items on certain branches

Scenario:
The Testers group contains users that perform testing in code to find issues during the development cycle. Because their work is related to testing but not developing, they must have restricted access to any script directory.
Security policy to enforce:
Anyone part of the Testers group in the rep00 repository will not be allowed to change any item inside any script folder on the main, development, and release branches.
To enforce this security policy as an administrator:
  • Create a secured path related to any (relative path) script folder on the main, development, and release branches in the rep00 repository.
  • Deny the check in (ci) permission to the Testers group on the new secured path.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Path permissions dialog:

    Path permissions

  2. Add a new secured and relative path associated with any script folder, check the Configure branches after creating path option and then, click OK:

    Path permissions - Secured and relative path

  3. In the Branches window, select the branches that will be affected by this permission. In this example, the main, dev (development) and release branches are selected:

    Path permissions - Secured and relative path - Branches

  4. Click OK to select the branches or, optionally, type in an identification tag for this selection and click OK to save this secured path. Then, click the Add button related to Users and groups and select the Testers group. Click OK to add this group. Edit the permissions to the Testers group by denying the check in (ci) operation and then click OK to save this permission:

    Path permissions - Secured and relative path - Branches - Deny

Check the configuration:
If any Tester user tries to make a change to any item in any script path on the main or development or release branches then the following error messages will be displayed:

Path permissions - Secured and relative path - Branches - Deny

Path permissions - Secured and relative path - Branches - Deny


Prevent users from modifying any item on certain branches

Description:
The project manager has defined a new rule that consists of restricting changes to items in the development branch in the rep00 repository, to certain groups.
Security policy to enforce:
Any user belonging to the Release builders group will not be allowed to modify any item on the development branch.
To enforce this security policy, the administrator will do the following:
  • Create a new permission associated with the development branch in the repository rep00.
  • Disable the check in (ci) permission to the Release builders group.
How to configure the security policy as an administrator:
  1. The administrator will launch the Permissions window for the development branch from the Branches or the Branch Explorer views:

    Branch permissions

  2. The administrator will add the Release builders group and deny the check in (ci) permission and then click OK to save this permission:

    Branch permissions - Deny ci

Check the configuration:
So now, every time a Release builder user tries to change any item on the dev (development) branch, the following error message will be displayed:

Branch permissions - Deny ci


Prevent users from modifying any item except under a given path

Scenario:
The team has a new member. The project manager doesn't want that user to modify anything except those items under a specific path.
Security policy to enforce:
In this scenario, the user Eddie can't modify anything (anything under path /) except the items under the path /src/cm.
To enforce this security policy as an administrator:
  • Deny the checkin (ci) permission for everything for user Eddie.
  • Allow by overriding the checkin (ci) permission for the path /src/cm for the user Eddie.
How to configure the security policy as an administrator:
  1. Launch the Path permissions dialog by right-clicking the required repository from the Repositories view:

    Path permissions

  2. Select All branches under the path /, add the user Eddie and deny the check in (ci) permission. Then, click Apply to save this permission:

    Path permissions - Deny ci

  3. To make sure that Eddie can checkin under the path /src/cm, click Add to create a new secured path. In the new window, select or type the /src/cm. Then, click OK to save this new secured path:

    Path permissions - Create new secured path

  4. Select All branches under the path /src/cm, add the user Eddie and make sure that the Allowed ci permission is enabled, click override for the Denied ci permission, and keep it empty:

    Path permissions - Create new secured path and override ci permission

    Because the /src/cm path overrides a denied permission, the resultant ACL cleans the permission that the override mask defines and sets the permissions for the /src/cm path.
  5. Click OK to save this new configuration.
Check the configuration:
  • After denying the checkin (ci) permission under the path / and overriding the checkin (ci) permission under the path /src/cm for Eddie, he can checkin any change done on any item in /src/cm:

    Path permissions - Permission override

  • After denying the checkin (ci) permission for Eddie under the path /, Eddie gets the following error if he tries to checkin any change done everywhere except /src/cm:

    Path permissions - Permission denied

  • If you don't override the checkin (ci) permission for Eddie under the path /src/cm, Eddie gets the following error if he tries to checkin any change done in /src/cm:

    Path permissions - Permission denied


Give access to a particular path to a specific group

Scenario:
The team manager wants only members of one group to have access to a particular path.
Security policy to enforce:
In this scenario, you want to grant the developers group read access to the /src/root/foo.c path in the rep00 repository. Nobody else will have access to that path.
To enforce this security policy as an administrator:
  • Give every group read access to the root of the path.
  • Allow only the developers group to access /src/root/foo.c.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Path permissions dialog for the rep00 repository:

    Path permissions

  2. Click the Add button to create a new secure path. In the new window, type or select the / path. Then, click OK to save this new secure path:

    Path permissions - New secured path

  3. At this point, you must indicate which groups can access the root folder.

    To do this, click the Add button related to Users and groups, select the developers group, and click OK to add this group:

    Path permissions - Grant read access to developers - root folder

    Add the testers group. This way, both the developers and the testers groups can access the root folder and have the read permission granted:

    Path permissions - Grant read access to testers - root folder

  4. You must create the new secured path to grant read access only to the developers group. To achieve this, first click the Add button to create the new secure path /src/root/foo.c and then click OK to save this new secure path:

    Path permissions - New secured path

  5. Once this new secured path is created, complete these steps:
    1. Add the developers group to grant access to the new secured path /src/root/foo.c. To do this, click the Add button related to Users and groups, select the developers group, and click OK to add this group:
      Path permissions - New secured path
    2. Add the testers group and neither allow nor deny the read permissions. To do this:
      Important!

      You have to apply the following steps to every group that you don't want to access to the particular path.

      1. Click the Add button related to Users and groups, select the testers group, and click OK to add this group.
      2. Now, edit the permissions of the testers group to neither allow (override) nor deny the read permission:
        1. Select the read permission.
        2. Under the Allow column, uncheck the read allowed permission and click the override button. A "padlock" icon appears next to the empty allowed checkbox of the read permission:
          Path permissions - Do not allow and override read access to subdirectory
        3. Under the Denied column, ensure that the Denied checkbox for the read permission is empty:
          Path permissions - Do not allow and override read access to subdirectory
  6. Click OK to save these changes.
Check the configuration:
Suppose that Mike belongs to the developers group and john belongs to the testers:
Path permissions - Users and groups

To verify that Mike (developers group) can access the /src/root/foo.c path and John (testers group) can't:

  • If John updates his workspace (pointed to the rep00 repository), he will see all the content except the /src/root/foo.c path:

    Path permissions - testers group can't access

  • If Mike updates his workspace (pointed to the rep00 repository), he will see all the content, including the /src/root/foo.c path:

    Path permissions - developers group can access


Give access to a particular subdirectory, but not the entire tree

Scenario:
In this scenario, you want to grant read access to the testers group to only the /game/art subdirectory in the rep00 repository, but not the entire tree.
Security policy to enforce:
Deny all the permissions to a group to access the entire tree but let the group "read" a particular subdirectory.
To enforce this security policy as an administrator:
  • Deny all permissions to the group testers for path / (the root) in the rep00 repository.
  • Undo (do not deny) the read permission to the group testers by overriding the permission for the /game/art subdirectory.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Path permissions dialog for the rep00 repository:

    Path permissions

  2. Click the Add button to create a new secure path. In the new window, type or select the / path. Then, click OK to save this new secure path:

    Path permissions - New secured path

  3. Once the secured path is created, all the users and groups defined in the repserver will appear in the Users and groups list. You must indicate the specific users or group that will not access the root folder.

    To do this, click the Add button related to Users and groups, select the testers group, and click OK to add this group.

  4. Edit the permissions to the testers group by denying all the permissions (Deny all button) and click Apply to save these changes:

    Path permissions - Deny permissions root folder

  5. You must create a new secured path to grant the read access. To do this, click the Add button to create the new secure path /game/art and then click OK to save this new secure path:

    Path permissions - New secured path

  6. Once this new secured path is created, all the users and groups defined in the repserver will appear in the Users and groups list. You must indicate the specific users or group that will access the subdirectory /game/art.

    To do this, click the Add button related to Users and groups, select the testers group and click OK to add this group.

  7. Edit the permissions to the testers group by overriding the read permission:

    1. Select the read permission:
      Path permissions - Override read access to subdirectory
    2. Under the Denied column, ensure that the Denied checkbox for the read permission is empty (not checked).
    3. Under the Denied column too, click the override button. A "padlock" icon appears next to the empty denied checkbox of the read permission:
      Path permissions - Override read access to subdirectory
  8. Then, click OK to save these changes.
Check the configuration:
  • After denying all the permissions under the path / (root path) and overriding the read (denied) permission under the path /game/art, the members of the testers group are now able create a workspace for the rep00 repository and only access the subdirectory /game/art:

    Path permissions - Create workspace

  • If you don't grant read access to any subdirectory, if someone in the testers group tries to create a workspace for the rep00 repository, they will get the following error message as they don't have permissions to access the entire tree of the repository:

    Path permissions - Don't have enough permissions


Prevent changes on a branch

Scenario:
You want to restrict access to the revisions stored on the release branch and allow the developers to read data from that branch but not make any changes.
Security policy to enforce:
Deny all the permissions except the read access on a branch to a group.
To enforce this security policy as an administrator:
  • Disable all permissions except the view and read permissions for the developers group on the release branch.
How to configure the security policy as an administrator:
  1. Launch the Permissions window for the release branch from the Branches or the Branch Explorer views:

    Branch permissions

  2. Add the Developers group and edit their security policy by denying all the permissions except the read and view ones. Then, click OK to save the changes:

    Branch permissions - Read and view

Check the configuration:
If a developer tries to make any change, e.g. apply a label or change a comment on the release branch, then the following error message will be displayed:

Branch permissions - Read and view


Prevent users from accessing certain parts of the repository

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.

Important!
  • The minimum version required for both Plastic SCM Client and Server must be 5.4.16.750.
  • 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 server.conf file:
    <SecuredPaths>true</SecuredPaths>
    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:


Prevent users from updating certain parts of the repository

Important!
  • The users without effective read permissions won't be able to download (by doing an update) the secured paths.
  • If the user has permissions to read an item/path, they will have permission to see all its revisions from the History views.
Scenario:
Restrict read access to certain paths so that some parts of the repository are not visible to certain users.
Security policy to enforce:

In this scenario, Mike won't be able to update the /scr/tools path and any script folder in the dev and release branches.

To enforce this security policy as an administrator:
  • Create a secured path related to the /src/tools path in the rep00 repository.
  • Create a secured path related to any script folder in the dev and release branches in the rep00 repository.
  • Deny or remove the read permission to the user Mike for those paths.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Path permissions dialog:

    Path permissions

  2. 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:

    Path permissions - Secured path - Update

  3. Once the secured path is created, 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 download (by doing an update) and see that path. Edit the permissions by denying the read operation:

    Path permissions - Secured path - Update - Deny read

  4. Add a new secured and relative path associated with any script folder. Then, check the Configure branches after creating path option, and then click OK:

    Path permissions - Secured path - Update

  5. In the Branches window, select the branches that will be affected by this permission. In this example, the dev and release branches is selected:

    Path permissions - Secured path - Update - Branches

  6. Click OK to select the branches or type in an identification tag for this selection and click OK to save this secured path. Then, select the user. Edit the permissions by denying the read operation and then click OK to save this permission:

    Path permissions - Secured path - Update - Branches - Deny read

Check the configuration:
  • If the user Mike tries to update (download) any script path on the dev or release branches, he won't be able to see those secured paths:

    Path permissions - Secured path - Update - Deny read - Check configuration

  • If the user Mike tries to update (download) the /src/tools path, he won't be able to see that secured path:

    Path permissions - Secured path - Update - Deny read - Check configuration


Prevent users from diffing certain parts of the repository

Note: The Diff operation will show the secured paths, if the user has permissions to read the change in the destination changeset.
Scenario:
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:
  1. In the Repository view, launch the Path permissions dialog:

    Path permissions

  2. 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:

    Path permissions - Secured path - Diff

  3. 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:

    Path permissions - Secured path - Diff - Deny read

  4. Maria will make some changes: One in the /scr/tools path and another in the /src/cm path.

    Path permissions - Secured path - Diff - Deny read - Changes

  5. Then, Maria will save the changes (by doing checkin) and will run a diff:

    Path permissions - Secured path - Diff - Deny read - Changes

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:

Path permissions - Secured path - Diff - Deny read - Check configuration


Prevent users from merging certain parts of the repository

Scenario:
Restrict read access to certain paths so that some parts of the repository are not visible to specific users.
Security policy to enforce:
Mike won't be able to merge a branch if there are changes in the /src/tools path that he can't read.
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 for Mike for that path.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Path permissions dialog:

    Path permissions

  2. 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:

    Path permissions - Secured path - Diff

  3. Once the secured path is created, 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 merge and see that path. Edit the permissions by denying the read operation:

    Path permissions - Secured path - Diff - Deny read

  4. Maria will create two branches and make some changes: One in the /scr/tools path in the task01 branch...

    Path permissions - Secured path - Merge - Deny read - Branch

    ...and another in the /src/cm path in the task02 branch:

    Path permissions - Secured path - Merge - Deny read - Branch

Check the configuration:
  • Mike refreshes the Branch Explorer and he can see both branches. But if he tries to merge the task01 branch, the merge will fail and notify him that the merge can't proceed due to security restrictions. The merge is rejected because Mike doesn't have the read permission for every change in the source contributor:

    Path permissions - Secured path - Merge - Deny read - Check configuration

  • Mike can merge the task02 branch and switch to the task01 branch. But, he's not able to see the diffs of task01 branch because he doesn't have the read permission on /src/tools path:

    Path permissions - Secured path - Merge - Deny read - Check configuration


Prevent users from seeing the content of revisions of certain parts of the repository

Scenario:
Restrict read access to certain paths so that some parts of the repository are not visible to certain users.
Security policy to enforce:
The user Mike won't see the content of revisions under a path that he can't read.
To enforce this security policy as an administrator:
  • Create a secured path related to the /src/tools path in the rep00 repository.
  • Create a secured path related to any script folder in the dev and release branches in the rep00 repository.
  • Deny or remove the read permission for Mike for that path.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Path permissions dialog:

    Path permissions

  2. 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:

    Path permissions - Secured path - Update

  3. Once the secured path is created, 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 download (by doing an update) and see that path. Edit the permissions by denying the read operation:

    Path permissions - Secured path - Update - Deny read

  4. Add a new secured and relative path associated to any script folder. Then, check the Configure branches after creating path option, and then click OK:

    Path permissions - Secured path - Update

  5. In the Branches window, select the branches that will be affected by this permission. In this example, the dev and release branches are selected:

    Path permissions - Secured path - Update - Branches

  6. Click OK to select the branches, or type in an identification tag for this selection and click OK to save this secured path. Then, select the user. Edit the permissions by revoking the read operation and then click OK to save this permission:

    Path permissions - Secured path - Update - Branches - Deny read

Check the configuration:
  • The user Mike won't be able to see the content of the /src/tools path in any branch:

    Path permissions - Secured path - Cat - Check

  • Mike can't see the content of any script folder in the dev and release branches:

    Path permissions - Secured path - Cat - Check

    But, he can see the content of any script folder in any branch different from the dev and release branches:

    Path permissions - Secured path - Cat - Check

  • Mike can't see the content of a file in any script folder in the dev and release branches:

    Path permissions - Secured path - Cat - Check

    But he can see the content of a file in any script folder in any branch different from the dev and release branches:

    Path permissions - Secured path - Cat - Check


Prevent users from adding new lock rules to a certain repository

Scenario:
Allow users to add new lock rules. This permission controls access to the Lock and Checkout feature both in Plastic and Gluon.
Important: Your server version should be 8.0.16.3361 or higher.
Security policy to enforce:

In this scenario, the users in the testers group can't add new lock rules in any repository except in the doom3src repository. And the users in the developers group can add new lock rules in all the repositories.

To enforce this security policy as an administrator:
  • Remove the configlocks permission for the testers group in the repository server.
  • Allow the configlocks permission for the testers group in the doom3src repository.
How to configure the security policy as an administrator:
  1. In the Repository view, launch the Repository server permissions dialog:

    Repository server permissions

  2. Add the developers and testers groups.

    Add groups

  3. Remove the configlocks permission for the testers group in the repositories server...

    Repository server permissions - Remove configlocks to the testers group

    ...and ensure that the developers group has configlocks granted also in the repositories server:

    Repository server permissions - Allow configlocks to the developers group

    Click OK to save these settings.

  4. In the Repository view, launch the Permissions dialog for the doom3src repository:

    Repository permissions

  5. Allow the configlocks permission to the testers group:

    Repository permissions - Allow configlocks to the testers group

    And click OK to save this setting.

Check the configuration:
  • If John, who belongs to the testers group, runs a Lock and Checkout operation on a file in the doom3src repository, then John will be able to create a new lock rule:

    Testers can add new lock rules in doom3src repository

  • If John, who belongs to the testers group, runs a Lock and Checkout operation on a file in a repository other than the doom3src one, then John won't be able to create a new lock rule:

    Testers can't add new lock rules in info repository

  • If Mike, who belongs to the developers group, runs a Lock and Checkout operation on a file in any repository, then Mike will be able to create a new lock rule:

    Developers can add new lock rules in any repository


How to secure repositories at the Plastic SCM Cloud with the command line

Scenario:
You have three different repositories in your Plastic SCM Cloud organization, and you want to secure it so specific user groups can only view and use specific repositories.
Security policy to enforce:
In this scenario, the Core_group can only access the Core repository, the Art_group can only access the Art repository, and finally, the Doc_group can only access the Doc repository.
How to configure the security policy as an administrator:
Note:

The Plastic SCM Cloud comes with two default groups: Administrators and Developers. When you invite a new user, you can choose if it will be a cloud admin. In this case, the system adds the user to the Administrators group. The system adds everyone else to the Developers group.

  1. The owner of the Plastic SCM Cloud owner creates three new groups: Core_group, Art_group, and Doc_group.
  2. Now it's time to invite new users to the Cloud organization and add them to their right security group.

    That's everything you need to do from the web portal.

  3. To configure the repository access using the command line:
    1. Set a valid Plastic SCM root user. The root user can access the system regardless of the security configuration. cm setowner -user=mlucio@codicesoftware.com repserver:catacroquer@cloud
    2. Remove the Developers group from the root ACL. This will prevent new Developers users from accessing all the repositories by default. cm acl -group=Developers -allowed=-all -denied=-all repserver:catacroquer@cloud
    3. Allow the Core_group group to access the Core repository. cm acl -group=Core_group -allowed=+all rep:Core@catacroquer@cloud
    4. Repeat the steps for the Art_group and Doc_group groups at their pertinent repositories: cm acl -group=Art_group -allowed=+all rep:Art@catacroquer@cloud cm acl -group=Doc_group -allowed=+all rep:Doc@catacroquer@cloud

    The result is that the Core_group users can only access the Core repository, and Art or Doc repositories are invisible for them.
    And, the same happens for the Art_group and the Doc_group — they can only see and use their repositories, nothing else.


Avoid hacking the secured paths

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:

Path permissions - Secured path - Avoid hacking

The Plastic SCM security system detects that the permissions are different, and automatically this hacking is avoided.


Last updated