Re: svn commit comment for "svn log <file>" is not shown, if the commit includes any files I don't have read access for
"C. Michael Pilato" <[email protected]> Mon, 30 Nov 2009 11:21:11 -0500
| Newsgroups | gmane.comp.version-control.subversion.devel,gmane.comp.version-control.subversion.rapidsvn.devel |
|---|---|
| Organization | CollabNet, Inc. |
| Message-ID | <[email protected]> |
Monty wrote: > Hi svn-dev, > > I got stuck on a problem with "svn log" that firstly made no sense :) > But after figuring out how the "svn log" works, I would kindly request > an improvement request in a border case. > > Scenario: > > Within 1 repository, there are 2 folders: A & B. > Kate has access to A & B [let's say rw], John has access to B only. > > Now Kate makes a commit [let's say revision 5] that modifies files in > both folders: A/foo and B/bar. Being a pragmatic programmer she is, she > of course provides a commit message. > > Now whichever way Kate checks revision history, everything is ok. > However when John checks revision history [for the file visible for him, > i.e. B/bar], he does see the commit message. He does see the revision > [5], but not the message Kate carefully worded. > > The command John executed was "svn log --username john > https://svn-repository/B/foo". And to sysadmins' surprise, Apache error > log showed: "Access denied: 'john' GET svn-repository:/A/foo > > So... to sum it up: > * John does see all his commit comments > * John also sees Kate's commit comments, if her particular commit only > touched B]. > * If there's a commit by Kate that involves A & B, John does not see the > comment for that particular commit. > > It seems there is an assumption that if you have permissions to view a > file in a specific commit, you can see all files in the commit. In our > use case this is not (and can't be made) true. It might be because I'm reading the above incorrectly, but I don't think you've expressed the correct assumption that Subversion makes. The assumptions that Subversion makes are these: * A file whose contents are unreadable by user X might also have a pathname that user X shouldn't be allowed to see. * A log message in which paths A and B are changed might actually mention paths A and B by potentially-sensitive name. When you combine the assumptions, you understand Subversion's behavior. John isn't allowed to see any paths in A. Kate's commit to both A and B might mentioned paths in B. Therefore, John shouldn't see Kate's commit log. -- C. Michael Pilato <[email protected]> CollabNet <> www.collab.net <> Distributed Development On Demand ------------------------------------------------------ http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2425543 Please start new threads on the <[email protected]> mailing list. To subscribe to the new list, send an empty e-mail to <[email protected]>.
signature.asc
(application/pgp-signature, 197 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksT8PcACgkQokEGqRcG/W4+DgCfZo9KzfikhhZANv0dZO9QEtmU O0oAn1wZVePqhmgZWo76vJcLDkdTKVZd =xIgl -----END PGP SIGNATURE-----