This is not an authoritative answer to your question, but since no one
else seemed interested, I'll give it a shot.
Once the branch is copied out of the trunk/a/secret, it is no longer protected.
The access permission checking is for past versions of the files. ie,
you cannot see what a file looked like before it was copied from
trunk/a/secret to branches/1/a/secret. This should also apply to old
log entries, etc.
To test this, try "svn cat -r 'before_branching'
/branches/proj-1.0/a/secret/???" and replace before_branching with a
revision from before the branch and ??? with some path to a file.
If this is indeed the case, what you need to do is make sure your
admin group knows that when (preferably before) a branch is created
the permissions need to be updated.
On 4/27/07, Frank Wallingford <frank.wallingford@technologist.com> wrote:
> 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
>
>
--
Josh Gilkerson
Software Engineer
Google, Inc · MV-1600 Plymouth (HQ)
+1 (650) 253-1667 direct
+1 (859) 608-7827 cell
jwg@google.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 30 19:21:55 2007