Subversion Path-Based Authorization: Minimal Architecture Note for Per-Directory Access Control

Problem: one repository, multiple teams, per-directory access

\n

A central Subversion repository often holds code for several teams under a single path tree. The useful takeaway is that Subversion can enforce read/write rules per directory with server-side path-based authorization, but the authz file is static, server-trusted, and reload-sensitive. Do not implement access control in clients or scripts.

\n\n

Requirements that drive the design

\n

Fine-grained access within a single repository without splitting into multiple repositories. Rules must be enforced on the server, not the client, and must be auditable. Identity must come from an existing provider: Apache with Basic auth or LDAP for http(s) access, or svnserve with SASL or password file for svn:// access. Encryption for data in transit is separate; authz is authorization only.

\n\n

Smallest suitable design

\n

Choose one server mode and keep the authz file minimal.

\n

svnserve with authz-db

\n

Enable authorization in the repository's conf/svnserve.conf. The file is edited as the repository owner, typically root or the svn service user.

\n

[general]\nanon-access = none\nauth-access = write\npassword-db = passwd\nauthz-db = /etc/svn/authz

\n

The authz file defines groups and path rules. Repository-relative paths are used.

\n

[groups]\ndevs = alice, bob\nqa = carol\n\n[/]\n* = r\n\n[/trunk]\n* =\ndevs = rw\n\n[/trunk/secret]\n* =\ndevs = r\n\n[/branches/qa]\n* =\nqa = rw

\n

Rules are evaluated from most specific to least specific. An empty permission denies access. The authz file must be readable by the svnserve process.

\n

Apache with mod_authz_svn

\n

For http(s) access, load mod_authz_svn and point to a single authz file for multiple repositories.

\n

DAV svn\nSVNParentPath /var/svn\nAuthType Basic\nAuthName \"Subversion\"\nAuthUserFile /etc/svn/passwd\nRequire valid-user\nAuthzSVNAccessFile /etc/svn/authz

\n

Apache evaluates the authz file per request; svnserve reads it at startup. The same authz syntax applies.

\n\n

Trust and data boundaries

\n

The client is untrusted. All enforcement happens server-side. The authz file is trusted configuration. It must not be writable by unprivileged users and must not contain secrets. Authentication credentials are separate from authorization rules. Path-based authz does not provide encryption; use HTTPS or svn+ssh for data in transit. Authz rules are per repository; there is no inheritance across repositories.

\n\n

Operational checks

\n

Verify configuration before relying on it.

\n

\n
• Confirm the authz file path in svnserve.conf or Apache config points to the intended file and the file is readable by the Subversion process.
\n
• Check syntax by inspecting for duplicate sections and correct group names. Subversion 1.8+ supports wildcards in paths; older versions behave differently.
\n
• Test denial: as a user who should be denied, attempt svn log or svn checkout on a restricted path from a client machine. Expect server-side denial, not a client error.
\n
• Test allow: as a member of an allowed group, attempt a commit to an allowed path. The operation should succeed only if both authentication and authorization pass.
\n

\n

For svnserve, changes to the authz file require a service reload or restart to be picked up. For Apache, changes are typically picked up per request, but verify with your MPM and configuration.

\n\n

Failure modes

\n

Misconfigured authz file can lock out legitimate users or unintentionally expose paths. A missing trailing slash changes the scope of a rule. An overly permissive [/] * = rw overrides more specific denies unless ordering is understood. If the authz file is unreadable, svnserve may deny all access or fall back to default depending on version and configuration. Because authz is static, dynamic group membership requires external synchronization to the file.

\n\n

When the design should change

\n

Consider a different approach when path-based rules become unmanageable: many repositories needing different policies, frequent group changes, or need for integration with enterprise LDAP groups. Apache with mod_authz_svn can centralize authz across repositories, but each repository still needs its own section. If auditability, dynamic membership, or per-action policy is required, evaluate migration away from Subversion path authz toward a system with native fine-grained access control.

\n\n

Limitations

\n

Authz is not a substitute for encryption. It is not version-controlled by default; changes are opaque unless you version the authz file yourself. It does not restrict access to repository metadata like svn list on parent directories unless those directories are explicitly denied. Practical verification is the only reliable check: attempt access as both allowed and denied users and confirm server-side enforcement.