Re: [SVN] Re: [SVN] Re: SVN and LDAP
From: Adam Hubscher <offbeatadam_at_gmail.com>
Date: Mon, 21 Apr 2008 11:01:35 -0500
Well, now this begs the question on the following (I haven't had time
Does PROPFIND require root directory access in order to access lower
In other words...
Can I not ALLOW propfind on /, but allow propfind only on /branches/
Ultimately, the overall goal is to limit access to a specific
So... being able to limit the actual use of PROPFIND at all, and then
When I get a moment today here at the office I'll try it on the future
--- "I'm not going to die. I'm going to find out if I'm really alive." - Spike Spiegel, Cowboy Bebop. "Do not attribute to malice that which can be easily explained with stupidity." - Hanlon's Razor On Apr 21, 2008, at 10:07 AM, James CE Johnson wrote: > 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.orgReceived on 2008-04-22 09:24:57 CEST
This is an archived mail posted to the Subversion Users mailing list.