I looked into this issue more deeply, to try and understand a little better
what has happened.
In that search, I found that some of my assumptions in quoted email were
So, as an update to this thread:
1. Both svnserve & mod_authz_svn have the same problem:
if a user needs access on a branch, she has to have read access on the
repository root as well.
Presumably caused by this piece of code:
libsvn_repos/commit.c: since r15608
/* Check read access to root */
SVN_ERR(check_authz (eb, "/", eb->txn_root, svn_authz_read, pool));
2. This problem typically impacts teams that store more than one project in
a repository, where the projects are subfolders in the repository root
3. Implementing an svn_authz_execute access right and exposing in the authz
config file is imho not a good idea because:
- you have to add users in two places, both in the folder they need write
access to and the root folder for execute access.
- there's no other usage scenario for execute access rights but the
non-recursive directory access feature as described in issue #2298.
So I propose to introduce the svn_authz_execute access right internally, but
to not expose it to the outside world. Instead, svn_authz_execute is granted
on a folder automatically when the user has read or write rights on the
folder or one of its subfolders.
So in this case the folder we check on is the repository's root folder, the
svn_authz_execute access right is granted whenever someone has r/w access
somewhere in that repository.
I was thinking of implementing it like this:
right before the recursive access check, check if we're querying for
If that's the case, invoke a function similar to authz_get_global_access
to check if the users has read access to any of the folders subfolders.
Would be nice if anybody with more knowledge about that code and
functionality can provide a decisive answer so I can start working on a
> -----Original Message-----
> From: Lieven Govaerts [mailto:firstname.lastname@example.org]
> Sent: zondag 15 januari 2006 2:40
> To: 'svn-dev'
> Subject: Problem with svnserve 1.3 authz, writing on
> subfolder requires read access on root.
> people testing the new authz code in svnserve 1.3 reported a
> problem on the users list. Apparantly, a user with write
> access on a folder in the repository also needs read access
> to the '/' folder, otherwise she'll get 'Access Denied'
> errors on commits to that folder.
> > My intention was to give a particular user read/write access to a
> > single
> directory only, e.g.:
> > [/]
> > foo = rw
> > [/open]
> > bar = rw
> > User bar can now read only from /open and no other directory.
> > Unfortunately any write to /open returns with an "Access denied".
> > With root read access enabled for bar, writes now succeed, e.g.:
> > [/]
> > foo = rw
> > bar = r
> > [/open]
> > bar = rw
> > [/other]
> > bar =
> A check in the code, and short discussion with David Anderson
> learned that:
> - svnserve requires read access to the repository root for commits.
> - this behaviour is by design.
> - mod_authz_svn doesn't have this behaviour, making both
> implementations of the same authz model incompatible
> I consider this a bug in svnserve, since the behaviour
> expected by svn admins is the mod_authz_svn model.
> The root cause of this issue in svnserve seems to be the lack
> of an 'execute bit' in the authz component. An 'execute bit'
> specifies 'cd into folder'
> rights for users, without giving them read access on the
> content of that folder.
> So, the suggested solution is to add to ability to specify
> the execute bit for folders in the authz file. Where the root
> folder now needs read rights, they can then be lowered to
> execute rights.
> Attached patch provides this ability. The patch is not ready,
> I attached it as a way to show what I mean. This patch is
> based on the patch attached to issue #2298 ( that issue seems
> to be a solution in search of a problem? )
> Some questions:
> - How come that mod_authz_svn does not have the same problem?
> Maybe it assumes implicite execute rights on the root folder?
> - Since this problem was already known, can someone point me
> to the relevant discussions on the dev list?
> - What are other people's thoughts on this topic?
> Implementing this fix for mod_authz_svn can - depending on
> the answer on my first question - break compatibility for
> authz files, so I think it should be discussed and agreed
> upon very thoroughly.
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.19/231 - Release Date: 16/01/2006
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jan 18 01:46:26 2006