I would also think that mod_authz_svn would notice that the user trying to
copy the protected folder into a branch doesnt have access to read it and
would not copy it, but without some experimentation I do not know for sure.
On 4/30/07, Josh Gilkerson <jwg@google.com> wrote:
>
> 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:53:22 2007