Understanding VisualSVN Server authorization

VisualSVN Server gives you the ability to grant access to selected users while keeping others from accessing confidential files in your repositories. From a user perspective, access control in VisualSVN Server looks close to the similar functionality in the Windows file system. However, there are significant differences which may cause difficulties for novice Subversion users.

This article describes the basic principles of access control in VisualSVN Server. It also describes the main differences from the Windows Access Control.

Tip

You can setup Repository Management Delegation feature in order to delegate access control tasks to non-admin users. The feature enables remote access rules management for project managers, team leaders or other non-admin users via the standalone VisualSVN Repository Configurator tool. For setup instructions, see the article KB62: Getting started with Repository Management Delegation.

Access rules

Access control in VisualSVN Server is implemented using the standard path-based authorization feature built-in to Subversion. The access rights are configured using the access rules in the following simple form:

<user/group name> = <access level>.

Access rules configuration in the VisualSVN Server

The following access levels can be explicitly configured for an access rule:

No Access
Read Only
Read/Write

An access rule is shown as inherited if it is defined for the parent path and is propagated to the current path without overloading (see the topmost radio-button on the screenshot).

Multiple access rules can be configured for each path in the repository. Access is prohibited for all users if there are no access rules defined (directly or through inheritance) for a given path.

Note that VisualSVN Server Manager shows visual indicators that help you find explicit access rules in the repository tree view and distinguish between explicit and inherited access rules on the Security tab. Explicit access rules always marked with a red asterisk (*) character near the access rule icon on the Security tab and near the repository subtree element in the tree view.

The screenshot shows that there is an explicit access rule on /MyProject/trunk for EXAMPLE\Developers and an access rule for EXAMPLE\Testers inherited from /MyProject. Both these nodes are marked with a red asterisk in the tree view.

Other nodes in the repository tree do not have explicit permissions and are not marked with a red asterisk.

Access rules applicable to a particular user

Access rule is applicable to a user in the following cases:

if it is configured for this particular user;
if it is configured for a group, which directly or indirectly includes this user.

Important

When using Windows Authentication, users that have been added to a group must log off and then log on again for corresponding access rules to take effect. That is due to the user's group membership information contained in the access token being updated only when the user logs on. For more information, see the Access Tokens Technical Reference.

If multiple access rules are being applied to one user, they behave according to the principles described in the following sections.

The principles of access control

The following two basic principles are preserved in the process of determining the access level for a given user: inheritance principle and priority principle.

Inheritance principle: access rights configured for a given path are inherited by all its children paths. There are the following substitution rules:

Access rights for a given path override access rights configured for its parent paths.
Access rights substitution is performed on a per-user basis.

Consider how the inheritance principle is preserved:

In this example, the user harry gets no access to the folder MyProject.

Inherited access rights will be overridden according to the clause a) of the inheritance principle.

In this example, the user harry gets a read only access to the folder MyProject.

The user harry is a member of the Developers group. That's why the inherited access rights will be overridden according to the clause a) of the inheritance principle.

In this example, the user sally gets a read/write access to the folder MyProject.

The user sally is NOT a member of the Developers group. That's why the inherited access rights will not be overridden according to the clause b) of the inheritance principle.

Priority principle: the rule with the most wide access level will be chosen if there are several access rules configured for a given path and applicable to a given user.

Consider how the priority principle is preserved:

In this example, the user harry gets a read/write access to the repository MyRepository.

The user harry is a member of the Developers group and both access rules are applicable to him. The rule with the most wide access level will be chosen according to the priority principle.

Differences from Windows Access Control

Windows Access Control has two types of access rules: deny- and allow-rules. The deny-rules have the priority over the allow-rules and help to configure fine-grained access rights.

On the contrary, Subversion path-based authorization does not have the deny-rules. It is often overlooked that the "No Access" access level is not the same as the deny-rule. If you are already familiar with Windows Access Control, the following examples should give you clarity on how to workaround the same access scenarios with Subversion path-based authorization.

Consider a typical example of joint allow- and deny-rules usage in Windows Access Control. Suppose that you need to grant Full Control permissions to everyone in the Developers group but the user harry. In this case, you can configure access rules as follows:

Take a look at the standard Windows File Explorer layout.

In this example, only the user sally gets Full Control access to the folder MyWorkplace.

Deny-rule is configured for the user harry. Access will be prohibited for this user because the deny-rules have a priority over the allow-rules.

Following the same approach in Subversion you get a different result. It is essential that "No Access" does not have the priority over wider access rules. The following example illustrates the mistake you want to avoid:

This example illustrates why the Windows approach does not work for Subversion.

The "No Access" rule is configured for the user harry. However, being a member of the Developers group, he still has read/write access to the repository MyRepository. As it follows from the priority principle, the wider read/write access rule overrides the "No Access" rule.

Naive assumption in this example is that access is explicitly prohibited for the user harry. That is not true because "No Access" is not a deny-rule.

Without the deny-rules you have to follow a different approach. Rather than prohibiting access, Subversion access rules imply that wider access is initially granted only to a subset of users that must have that access level. In practice, it can be done by adding those users to a separate group.

For example, to grant read/write access to everyone in the Developers group except for the user harry, you can create an additional SeniorDevelopers group. Then add the authorized users to the new group and grant that group with the required access:

In this example, the user harry has no access to the repository MyRepository.

The Developers group does not have any access rules configured. However, the user sally is added to the SeniorDevelopers group and gets read/write access to the repository MyRepository.

Access can be also granted to each user individually, as shown in the following example: