On Wed, Jun 25, 2008 at 9:17 AM, John Peacock
<john.peacock_at_havurah-software.org> wrote:
>
> I don't think it is either a bug or a misfeature, merely an outgrowth of the
> existing path-based security model. Yes, it requires full permissions to
> create a tag of folders containing potentially sensitive or otherwise
> restricted folders. But even in that case, an additional stanza would have
> to be added to the security to maintain that restriction in the tag's tree.
>
Actually, I don't think you would need the additional stanza depending
on the implementation. The implementation I have in mind for "svn cp
foo bar" is something like
1. If user doesn't have read access to foo, print a warning and skip foo
2. Else, copy all files in foo to bar/
3. For each directory baz in foo, call "svn cp foo/baz bar/baz"
This way, if there is a tree with foo at the top with sub-directories
A and B where a user can read foo, foo/A but not foo/B, then the tag
or copy operation correctly copies over only the things the user has
access to and no additional work is required to maintain security in
the tag's tree. This seems to be the way "svn co" works in that it
simply skips sub-directories the user does not have access to.
After you description of "svn cp", I basically wrote my own scripts to
implement tagging as described above and that seems to work without
any problems. Still, it would be nicer if the built-in "svn cp" did
that if possible.
> I believe the vast majority of projects where specific folders are
> restricted do so at the project level, so that the restrictions are
> inherited from above by trunk/branches/tags for each project. Either a user
> has full access to all of a project, or doesn't have access at all. Trying
> to limit access within a project is not a typical use-case, because of the
> difficulties you've stumbled over.
I can accept that this may not be a typical use case for most users,
although the thread at
http://svn.haxx.se/users/archive-2005-09/0504.shtml outlines a variety
of reasonable cases where this functionality is desirable. Luckily,
svn is designed in such a way that it is easy to write my own scripts
to control it. Easy script-ability of svn is great.
> There has been some discussion in the past, but no firm designs, of possibly
> adding an inherited property model to the repository. This would permit
> fine-grained folder and file security, much like in a filesystem (by
> maintaining the security in the repository itself). But there are more
> edge-cases than you can imagine with such a system, so the discussion hasn't
> proceeded anywhere near a design document that could be used to implement
> it.
Yes, I can see how that would be a good solution but difficult due to
all the corner cases.
Personally, I think the best approach would be to make "svn cp" work
more like "svn co" and ignore directories the user does not have
access to. I don't see any obvious problems with such an approach, but
that could be because I don't know much about the implementation
details. I suspect the main problems might be in how such things would
interact with the recently added svnmerge.
Thanks,
-Emin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-26 15:54:45 CEST