OK, I got some time to pound on this during the afternoon and spent some
quality time in the source... I'm at home now and my notes are at the
office so I'll try to do this from memory.
Let's say we have the repository paths .../parent and .../child and we
want only a certain group of people to be able to checkout or update the
child. In my initial pass at this I did the following:
<Location /svn/myRepo/parent>
Require valid-user
</Location>
<Location /svn/myRepo/parent/child>
Require group ...
</Location>
This will protect against the following:
svn ls http://myserver/svn/myRepo/parent/child
svn co http://myserver/svn/myRepo/parent/child
and commits against the child.
It will *not* protect against:
svn co http://myserver/svn/myRepo/parent
which will check out the child as it processes parent.
When we look in the apache logs we see a PROPFIND on the parent and some
internal things but no mention of the child.
While digging through the mod_dav_svn source I discovered that, as it
traverses the directory tree, it does an internal GET on each path to
determine if the path is accessible. However, these GETs use the internal
subversion URIs, not the ones that we naturally think of. So, to protect
our child path, we can add another <Location/> tag thusly:
<Location ~ /svn/myRepo/!svn/ver/[0-9]+/parent/child>
Require group ...
</Location>
Note that this needs to come after:
<Location /svn/myRepo/!svn>
Require valid-user
</Location>
I wasted a couple of hours because I had that nugget tucked away in an
included conf file following the one I was tweaking.
What's really nice about this is that a checkout of the parent silently
ignores the now-protected child and populates the local workspace with
everything that is unprotected.
I haven't tested it (yet) but it is reasonable to assume that the same
technique will work with the more complicated <Limit/> and <LimitExcept/>
tags.
The next few days are going to be busy but when I get a moment I'm going
to update the blog post to include this so that anyone referencing it
won't go pulling their hair out.
> 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
>
>
---------------------------------------------------------------------
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:02:24 CEST