[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

mod_authz_svn and branches (copying)

From: Frank Wallingford <frank.wallingford_at_technologist.com>
Date: 2007-04-28 04:54:57 CEST

I'm using subversion-1.4.3 (r23084) on a Linux server, with mod_dav_svn
and mod_authz_svn.

I am trying to lock down a repository of this format:

  /trunk/a/a
  /trunk/a/secret
  /branches/proj-1.0/a/a
  /branches/proj-1.0/a/secret

I want the "secret" directory to be non-readable to most users.

In Apache, I'm using "SVNParentPath" to point to a directory like /foo.
The /foo/proj directory is my target repository.

I am also using "AuthzSVNAccessFile", and the contents of that file look
like so:

  [groups]
  dev = user1, user2
  admin = user1

  [/]
  * = rw

  [proj:/]
  * = r
  @dev = rw

  [proj:/trunk/a/secret]
  * =
  @dev =
  @admin = rw

Now, the permissions seem to be working fine on /trunk/a/secret. "user1"
has read and write access to /trunk/a/secret, but "user2" has no access at
all. This is exactly what I want.

However, after reading the documentation, I was under the impression that
the branches would have the same permissions. Since the branches are
copies, I thought that the history of /branches/proj-1.0/a/secret would
reveal that it used to exist in a protected location, meaning that it
should still be protected.

Here is the documentation that had me convinced that this should work as I
expected:

  The mod_dav_svn module goes through a lot of work to make sure that
  data you've marked unreadable doesn't get accidentally leaked. This
  means that it needs to closely monitor all of the paths and
  file-contents returned by commands like svn checkout or svn update
  commands. If these commands encounter a path that isn't readable
  according to some authorization policy, then the path is typically
  omitted altogether. In the case of history or rename tracing, e.g.
  running a command like svn cat -r OLD foo.c on a file that was renamed
  long ago, the rename tracking will simply halt if one of the object's
  former names is determined to be read-restricted.

However, "user2" has full access to /branches/proj-1.0/a/secret.

Is this supposed to work? If not, is there any way to protect this branch
and future branches without manually adding each one to the access config
file? Perhaps I'm doing something wrong; enlightenment would also be
appreciated.

Thanks,

-Frank

--
----------------------------------
Frank Wallingford
frank.wallingford@technologist.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 28 03:56:49 2007

This is an archived mail posted to the Subversion Users mailing list.