Reconfiguring access permissions after upgrade to VisualSVN Server 2.7

In VisualSVN Server 2.5 and earlier versions, authorization settings were stored in a single file for all repositories. Starting from version 2.6, authorization settings are stored separately in dedicated per-repository files. This is a substantial change in the authorization system that leads to better isolation between repositories and enhanced authorization performance.

VisualSVN Server 2.7 installer automatically migrates server-wide access rules during an upgrade from older versions. Unfortunately, it’s not always possible to unambiguously migrate all server-wide access rules and manual reconfiguration may be required. VisualSVN Server 2.7 installer generates a detailed report that helps you to understand which rules are migrated successfully and which ones require your attention. Directions on how to interpret the upgrade report are provided below.

VisualSVN Server Upgrade Report

VisualSVN Server 2.7 installer makes a backup of your previous authorization settings and generates an upgrade report. The upgrade report contains detailed information about authorization settings migration and helps you to determine which rules failed to migrate and must be reconfigured.

The VisualSVN Server 2.7 upgrade report is a table that lists all repositories connected to your instance of VisualSVN Server. Repositories with successfully migrated access permissions are marked by green color. There is no need to perform manual reconfiguration if everything is green.

Repositories that require manual permissions reconfiguration are marked by red color and the corresponding statement. There is a subtable called permissions snapshot for each of these repositories.

Permissions snapshot is a table with three columns: Account, Before upgrade and After upgrade. Each row in this table corresponds to a single access rule. Access rules marked by red “(removed entry)” label are failed to migrate and require manual reconfiguration. VisualSVN Server 2.7 installer failed to migrate these access rules unambiguously and they were removed. For these rules, the Before upgrade column contains the server-wide access level that was configured for the Account on the repositories root level.

Common examples of upgrade report entries are briefly described below.

Cases when manual reconfiguration is required

Each example below explains a particular case when VisualSVN Server 2.7 installer fails to migrate access rules unambiguously. Also there are general recommendations on how to reconfigure access permissions in each of these cases.

a. Overlapping user accounts

Suppose that you have VisualSVN Server 2.5 with a single repository named MyRepository. There are two access rules in your configuration:

• Group Employees is granted Read / Write permission access to the repositories root.
• User jack is granted No Access permission to the root of MyRepository.

Also let’s assume that jack is a member of the Employees group.

In this case the installer is unable to move the Read / Write access rule for Employees group to the root of MyRepository. This happens because a shift of the server-wide Read / Write access rule will provide jack with unwanted Read / Write access to the repository (due to an effect of the priority principle explained in KB33). That’s why the installer removes the Read / Write rule for Employees and generates the following upgrade report:

You are requested to manually reconfigure access permissions for MyRepository repository. The general recommendation is to create additional group and grant it Read/Write access to MyRepository.

For example, you can create a group called Developers that does not contain user jack and provide this group with Read / Write access to the repository.

b. Overlapping groups

Suppose that you have VisualSVN Server 2.5 with a single repository named MyRepository. There are two access rules in your configuration:

• Group Employees is granted Read / Write permission access to the repositories root.
• Group Testers is granted Read Only permission to the root of MyRepository.

Users harry and sally are members of both groups, so these groups overlap each other.

In this case the installer is unable to move the Read / Write rule of group Employees to the root of MyRepository. This happens because a shift of the server-wide Read / Write access rule will provide the overlapping users with unwanted Read / Write access to the repository (due to an effect of the priority and the inheritance principles that are explained in KB33). The installer removes the Read / Write rule for group Employees and generates the upgrade report entry:

You are requested to manually reconfigure access permissions for the MyRepository repository. The general recommendation is to consider which user and group accounts should have access to the MyRepository repository and set access rule explicitly on the repository:

For example you can create a new group Developers, include users who need access to the repository and provide the group with Read / Write access to the repository.

c. Non-overlapping groups

Suppose that you have VisualSVN Server 2.5 with a single repository named MyRepository. There are two access rules in your configuration:

• Group Domain Admins is granted Read / Write permission to the repositories root.
• Group Testers is granted Read Only permission to the root of MyRepository.

Both of these groups do not have common members.

The VisualSVN Server 2.7 installer always assumes the fact that groups overlap each other. In other words, the installer does not attempt to determine whether groups overlap or not. That’s why in this case the installer is unable to move the Read / Write rule of Domain Admins group to the root of MyRepository and the rule is removed.

You are required to determine whether Domain Admins and Testers groups overlap and reconfigure access permissions accordingly.

For this case you will see the following upgrade entry:

You are requested to manually reconfigure access permissions for the MyRepository repository. The general recommendation is to determine whether these groups overlap or not and set access permissions accordingly. If you are sure that these groups don’t overlap then feel free to shift the Read / Write rule to the root of MyRepository.

In this case Domain Admins and Testers groups do not overlap and you can shift the Read / Write access rule to the root of MyRepository without any further actions.

See also