Access denied failure during mid-session authz revocation

Question

Path-based Authorization and Credential Persistence
Apache Subversion implements least-privilege access via path-based authorization (authz) files, which decouple identity verification from directory-level permissions. While the authentication provider handles the initial identity check, the authz file determines the specific read/write capabilities for each repository path.

Credential Cache Uncertainty
A technical uncertainty exists regarding the behavior of the SVN client when server-side permissions are revoked mid-session. Because the client often caches credentials to avoid repeated authentication prompts, it is unclear how the system handles the transition when a user's access is stripped from the authz configuration while a working copy is still active.

The interaction between the client-side credential store and the server's permission re-evaluation varies between the svnserve daemon and mod_dav_svn. It is not explicitly documented whether a change in the authorization file immediately triggers an access-denied response for the next operation or if the session persists until the cache expires.

Does the SVN client trigger a re-authentication challenge immediately after a server-side authz revocation?
  How does the mod_dav_svn backend signal the client to invalidate cached credentials when path-based permissions change?

Siddharth · Answer

Direct answer
No. The SVN client does not trigger a new authentication challenge immediately after a server-side authz revocation. It keeps using cached credentials until the next repository operation. At that point the server re-evaluates path-based authorization and returns 403 Forbidden for the revoked path. mod_dav_svn sends no signal to the client to invalidate cached credentials when path-based permissions change.
Likely explanation
Authentication and authorization are separate in Subversion. The credential cache stores proof of identity, not a permission decision. Because authz is checked per operation on the server, a mid-session authz change takes effect on the next request, but the client cannot know the permission changed until it receives the denial.
Backend differences

svnserve generally re-evaluates authorization per connection or operation, so revocation often appears on the next command.
mod_dav_svn with Neon or serf may reuse cached HTTP credentials across requests, so the client can resubmit the same identity while the server denies the path. Observed timing depends on client configuration, HTTP keep-alive, and cache lifetime.

Treat exact timing as version-sensitive; verify against your specific Subversion release.
Steps for this case

Run svn --verbose info REPOSITORY_URL or svn --verbose update after editing authz.
Check the response code: 403 Forbidden means the revocation is enforced; 401 Unauthorized means the credential itself was rejected.
For mod_dav_svn, reload Apache so the server reads the updated AuthzSVNFile.
If stale access appears to persist, rename the credential cache directory and retry to force fresh credentials: ~/.subversion/auth/ on Linux or macOS, %APPDATA%\Subversion\auth\ on Windows.

One missing detail
Which server backend and Subversion versions are you using? That determines whether to expect per-operation re-evaluation or HTTP credential reuse, and it changes the reload step.

Access denied failure during mid-session authz revocation

Path-based Authorization and Credential Persistence

Credential Cache Uncertainty

1 answer

Direct answer

Likely explanation

Backend differences

Steps for this case

One missing detail

Your perspective belongs here.

1 question comment

“Next request” may not mean “next command”