Wildcard Access Control and Path Based Permissions in TeamForge

The story so far

Traditionally, access control to subversion repositories is achieved using an “authz” file. This is a text file that can contain both repository specific and global rules to decide which users or group of users can read or write to which parts of the repository. This requires using an apache module called mod_authz_svn which is developed as a part of the Apache Subversion project.

A typical authz file looks like this:

[groups]
dev = alice, bob, charlie
testing = dorothy, elliot, frank
secretgroup = alice, frank
build = bob

[/]
* =
@dev = r
@build = r
@testing = r

[/trunk]
@dev = rw
@testing = r
user1 = rw

[project1:/branches/secretfeature]
@secretgroup = rw
* =

[project2:/branches/featurebranch1/builds]
@build = rw
@dev = r

Usually, there are a few users who are given access to this file at the filesystem level and are the only ones who can modify these rules. With the authz format, these repo admins are limited to using only absolute paths to grant or deny access.

This is feasible only for a handful or up to a few dozen repos. When the number of repositories grows large, it becomes very difficult to maintain a large number of rules in a single file. Even if the responsibility is shared by a group of admins, there may be issues with the concurrency of the file (multiple people editing the file simultaneously)

Enter TeamForge

CollabNet’s flagship product TeamForge offers, among many other Enterprise grade features, its own authentication and authorization module called mod_authnz_ctf. It offers an intuitive project based and repo based UI to make the lives of repo admins easier. With the abilty to create roles and groups, repo admins save a lot of duplicated effort to maintain a large number of repositories.

Starting with TeamForge 7, repo admins can take advantage of some simple yet powerful wildcard notations – * and ** to author path based permissions (PBPs)

Let’s see when and how these wildcards can be leveraged with some scenarios.

Scenario 1:

If a particular path under every branch need to be access controlled, achieving this using authz rules can be very time consuming and inefficient. The admin will have to write a separate rule for every branch in the repository like this:

[/branches/foo/build]
@build = rw
@dev = r

[/branches/bar/build]
@build = rw
@dev = r

…
…

[/branches/baz/build]
@build = rw
@dev = r

New branches that are created need new rules to be written. Wildcards can solve this problem elegantly with just one rule:

/branches/*/build

Build users will have a role that grants read-write access to that path and developers will have read-only access.

Scenario 2:

If there is a particular file/folder pattern that needs to be restricted in a repository: For example, if only release managers should be able to modify .iso files. It is impossible to define such a rule using authz files. With TeamForge, one can write a rule like:

/trunk/build/*.iso

This will apply to all files and folders that end with .iso under /trunk/build

Scenario 3:

If the folder structure is ambiguous across branches, and one needs to restrict access across multiple folder levels: For example, if the “build” folder should be restricted wherever it is within the repository, one can author a rule like:

/**/build

The ** matches any number of folder levels in the repo.  i.e the following paths will take on the permission specified by the above PBP:

/trunk/build
/branches/feature1/build
/trunk/external_module/build and also
/build

These wildcards can also be used in conjunction with each other, and thus providing very powerful constructs. For example:

/**/*.iso – Match any .iso file anywhere in the repo.
/branches/RB* – Match all branches whose names start with RB
/branches/*/*.txt – Match all .txt files one level under any branch.

Resolving ambiguity

It is important to remember that with wildcard support, it is possible to write more than one rule that matches a single path, leading to ambiguity:

/**/secret – read-only
/trunk/dev/secret – read-write

Both paths match the path /trunk/dev/secret

In this case, the conflict is between an absolute path (explicitly specified /trunk/dev/secret) and a wildcard PBP. In such a scenario, the permissions associated with the absolute path are applied.

If the path under consideration is /trunk/dev/secret/folder1/subfolder2/secret, both the above rules are still a match, however, since the wildcard rule is a more appropriate match (it matches the entire path upto the second “secret” directory) the wildcard rule is applied.

/**/secret – read-only
/branches/*/secret – read-write

If the path being modified is /branches/abc/secret, both the above rules match this path to the same extent and since both of them are wildcard rules, the more restrictive permission is applied (in this case read-only)

These notations and behaviors were designed with the average user in mind and in most cases will behave exactly like what one thinks is intuitively correct.