Re: [SVN] Re: [SVN] Re: SVN and LDAP

Well, now this begs the question on the following (I haven't had time
to set it up myself and test it out myself):

Does PROPFIND require root directory access in order to access lower
level directories?

In other words...

Can I not ALLOW propfind on /, but allow propfind only on /branches/
(branch)?

Ultimately, the overall goal is to limit access to a specific
directory or subset of directories, whereby the ability for the user
to checkout the entire project or an entire set of projects.

So... being able to limit the actual use of PROPFIND at all, and then
essentially ACL it as you go down the line into directories, would be
sufficient.

When I get a moment today here at the office I'll try it on the future
SVN server we have. I still have to sit down with its primary user
group and hash out how their management truly wants the security to
look, however I know that the further down I can drill it the better.

OffbeatAdam

---
"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.org