Subversion Authz: Missing Parent‑Directory Inheritance Constraint

Question

Subversion’s path‑based authorization (authz) allows administrators to assign read or write rights to any repository path without automatically granting those rights to parent directories.
This design choice means a user can successfully check out a deep path such as /trunk/project/src while lacking any permission on /trunk or /trunk/project. Operations that enumerate those parent directories—like svn list or GUI directory views—then fail with authorization errors, creating an inconsistent user‑facing workflow.
The subsystem does not provide a built‑in option to enforce hierarchical consistency, leaving administrators to decide whether to add manual rules, rely on client‑side workarounds, or request a strict inheritance mode.
Should Subversion introduce an optional inheritance flag in the authz file? How would enabling inheritance affect existing configurations and performance? What impact would it have on backward compatibility and administrative overhead?

Tasadduq Burney · Answer

Answer
Yes, Subversion could add an optional inheritance flag to the authz file; it should be opt‑in and default to off so existing configurations keep their current behavior.
Confirmed facts

Subversion’s authz evaluates each path rule independently; granting rw on /trunk/project/src does not imply any rights on /trunk or /trunk/project.
Because of that, a checkout of the deep path succeeds while operations that list parent directories (svn list, repository browsers) fail with an authorization error.
This behavior is the same for svnserve and Apache/mod_authz_svn.

Likely explanation
The design keeps the authorization check a simple longest‑prefix match, avoiding a tree walk that would require evaluating every ancestor rule per request.
What enabling inheritance would change

Backward compatibility: preserved only if the flag defaults to off; turning it on for an existing authz file would silently grant at least read access to all ancestors of every permitted path, so an audit is required before rollout.
Performance: each authz decision would need to check ancestor paths, adding a cost proportional to the depth of the tested path – typically a few extra rule evaluations, negligible for most servers but measurable under very high request rates.
Administrative overhead: reduces the need for manual parent‑stub rules, but makes the effective permission set less visible in the file, increasing the cognitive load when auditing exact grants.

Steps to verify the current behavior

Create a test repository and an authz rule that grants rw only on a deep path, e.g. [/trunk/project/src]alice = rw.
Run svn list svn://host/ (or the appropriate URL) – it should fail with an authorization error.
Run svn list svn://host/trunk/project/src – it should succeed.
Repeat the two checks under both svnserve and Apache/mod_authz_svn to confirm the behavior is consistent.

What to do today
Since no released Subversion version provides an inheritance flag, generate parent stub rules automatically (e.g., via a script or template) so that granting a deep path also writes explicit read‑only lines for each ancestor.

Subversion Authz: Missing Parent‑Directory Inheritance Constraint

1 answer

Answer

Confirmed facts

Likely explanation

What enabling inheritance would change

Steps to verify the current behavior

What to do today

Your perspective belongs here.

0 question comments