On 1/11/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> That document mentions the problem of O(N) behaviour for copy operations, in
> section 3 of each "chapter". It doesn't mention such a problem for any other
> situation. Do you want to patch it to warn of O(N) behaviour in other or all
> cases?
I'm talking about the section on revision properties:
--------------------------------------------
5. REVISION PROPERTIES
Users are allowed to attach arbitrary, unversioned properties to
revisions. Additionally, most revisions also have "standard"
revision props (revprops), such as svn:author, svn:date, and
svn:log. Access to revprops may be restricted, based on
readability of changed-paths.
* If a revision contains nothing but unreadable changed-paths,
then all revprops are unreadable and unwritable.
* If a revision has a mixture of readable/unreadable
changed-paths, then all revprops are unreadable, except for
svn:author and svn:date. All revprops are unwritable.
--------------------------------------------
The problem here is that 'svn log' is all about fetching revprops:
author, date, log message.
In order to decide which revprops are okay to display, all of the
changed-paths in a given revision have to be examined. This isn't
something that can be optimized away with clever uses of trees,
red-black elimination, etc. What must be determined is whether
* all the changed-paths are readable
* some of the changed-paths are readable
* none of the changed-paths are readable.
And that's just an O(N) search (where N == number of changed-paths in
the revision), no matter what you do. There's nothing predictable
about the changed-path list. If one of the changed-paths just happens
to be a child of another, it's still not useful to us; we can't make
any assumptions about the ACLs set up by the server process, or
whether there's inheritance or not. Our authz_read() callback
operates on single paths, and that's it.
So yeah, this is a case where security trades off for performance.
The tradeoff can be reversed by disabling path-based authorization
features completely. I don't see any other options...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 11 16:51:02 2006