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.

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

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 propogated 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 any access rules defined (directly or through inheritance) for a given path.

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

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

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:

  1. Access rights for a given path override access rights configured for its parent paths.
  2. 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 choosen according to the priority principle.

Differences from Windows Access Control

The main difference of Subversion path-based authorization from Windows Access Control is the lack of deny-rules. Deny-rules have the priority over allow-rules and might be useful to configure fine-grained access rights.

Consider a typical example of joint allow- and deny-rules usage in the Windows Access Control. Suppose that it's needed to configure access permissions for a given folder in the following way: full access should be granted to a Developers group excepting the user harry (assuming that harry is a member of the Developers group). In this case, you configure access rules as follows:

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

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

The similar technique is inaccessible in the VisualSVN Server because deny-rules are unavailable in the Subversion path-based authorization. The following example illustrates an error that is typical for novice VisualSVN Server users:

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

Naive assumption in this example is that access is explicitly prohibited for the user harry. That's not true because "No Access" is not a deny-rule. The user harry gets a read/write access according to the priority principle.

The following technique is applicable when it is required to grant access to a given user group excepting particular members:

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

Additional user group called TechLeads is required in this example, because deny-rules are unavailable in Subversion path-based authorization.

Last Modified: