Re: mod_authz_svn: cannot restrict access to subdirectories

Hi Ryan,

On Thu, Jun 28, 2007 at 04:50:02PM -0500, Ryan Schmidt wrote:
>
> On Jun 28, 2007, at 08:04, Christoph Ludwig wrote:
>
> >I am using mod_authz_svn 1.3.1 installed from the libapache2-svn
> >package of
> >Ubuntu 6.06. I want to give a group of colleagues from other
> >institutions full
> >access through https to some directory /trunk/a/b in one of our
> >repositories,
> >but not to the its parent directories.
> >
> >I found after some googling that I have to give them read access at
> >least to
> >the repository's top level directory / or any access to /trunk/a/b
> >is denied.
> >I can live with that since the top level directory contains nothing
> >I want to
> >protect. But I don't want them to read the intermediate directory
> >/trunk/a. However, all my attempts to refuse them access failed.
> >
> >Below are the relevant parts of my apache configuration and of the
> >authz. Can
> >anyone give me apointer what's wrong?
>
> According to the change log, that was fixed in Subversion 1.3.2. You
> should upgrade, preferably to the current version, 1.4.4.
>
> http://svn.collab.net/repos/svn/trunk/CHANGES
>
> >Version 1.3.2
> [snip]
> > * fixed: authz requires read access for root for writes (issue
> >#2486)

that is good to know, but as I said, I can live with issue #2486 for the time
being. The root contains only /trunk and /branches - these directory names
are hardly confidential. I therefore don't mind if the @project group has read
access to repA:/

My problem is that even though I explicitly took away all access permissions
for repA:/trunk/ from the group @project, the members of @project still can
read trunk's content. (I.e., 'svn ls https://my.domain/svn/repA/trunk/'
succeeds, and so does 'svn ls https://my.domain/svn/repA/trunk/a/'.)

I want the following access permissions enforced:

  [repA:/]
  @project = r

  [repA:/trunk/]
  @project =

  [repA:/trunk/a/]
  @project =

  [repA:/trunk/a/b/]
  @project = rw

Or is the behaviour I observe a consequence of issue #2486 that was not
mentioned on the issue tracker? (I'd rather keep the authz module packaged by
my distribution; but if someone confirms that this issue was fixed as well in more
recent versions, then I will do a manual upgrade.)

Regards

Christoph

-- 
FH Worms - University of Applied Sciences
Fachbereich Informatik / Telekommunikation
Erenburgerstr. 19, 67549 Worms, Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org