OK, sorry for the long delay. Sadly, I was able to reproduce Kevin's
scenario: Executing a checkout for a parent directory will also get you a
protected child's contents.
For instance, if I have .../svn/topLevel and .../svn/topLevel/protected
and a <Location .../svn/topLevel/protected/> tag that would otherwise
prevent me accessing the protected path, a checkout of .../svn/topLevel
will also give me .../svn/topLevel/protected.
This is because, as Kevin's log shows, Apache only sees the PROPFIND
request on the top-level directory and never knows about the
subdirectories. The actual content is embedded in the underlying DAV XML
chatter between the client and server.
The good news is that 'ls' and 'commit' for the child are still protected.
At least with 'commit' protection we can avoid unauthorized updates to
what should have been protected.
I don't currently have a solution that would prevent the checkout. I
suppose a workaround would be to tighten down the screws so that the most
restrictive permissions are at the top levels and then relaxed as needed
as you go deeper. It might also be possible to hide the actual repository
from direct access and use a set of aliases and redirects to get to the
various paths within it. I haven't explored this yet, though, so I don't
know if either one is actually manageable.
> "James CE Johnson" <jcej_at_tragus.org> wrote on 04/18/2008 01:48:50 PM:
>> Thanks for the kind words Adam. I hope I've saved you some pain :-)
>>
>> We have a similar situation where we use LDAP (well, AD fronted by LDAP)
>> to manage our users and groups. Redefining all of that "just" for SVN
>> would never fly. Integrating through mod_auth_ldap makes it all easy and
>> if I can automate the Apache rule generation (Kevin: Thanks for the
>> 'apachectl graceful' reminder!) then it more or less just runs itself
> for
>> the common case.
>>
>> I want to look into Kevin's "top-level checkout" issue Monday and see if
> I
>> can reproduce it in our environment. I'm pretty sure I solved that since
>> it is an obvious loophole but he's clearly experiencing it so I need to
> go
>> back to my notes and test system to figure it out.
>
> I'm only seeing a TortoiseSVN "top level" checkout do propfinds on:
> /kmr_test and /kmr_test/!svn. Therefore apache can't enforce the lower
> level path access, since tortoiseSVN isn't requesting information on
> each lower level directory.
>
> Maybe it works better on sub-sub-directories? (I.E. maybe the top level
> is special...???)
>
> Kevin R.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-22 08:19:12 CEST