> Ok, I quickly tried this again, and I get restricted behavior if
> I try and navigate using either the TortoiseSVN repo-browser or
> Internet Explorer, but if I use TortoiseSVN to checkout the
> top level folder, the subdir restrictions are not used:
>
> <Location /kmr_test>
> Require group CN=In_This_One,...
> </Location>
>
> <Location /kmr_test/private>
> Require group CN=Not_For_Me,...
> </Location>
>
> If I "checkout" /kmr_test, I get the contents of private, even
> without being in the group.
>
> Am I missing something?
No, that should work. I'm not in the office this afternoon so I can't
setup a testcase until Monday. I remember that it is particularly
sensitive to ordering but the ordering you have is the same as what I've
done. You might switch them just to verify that in case something has
changed. Also, check the apache logs and see what is actually being
requested by the client and how that aligns with your rules.
>
> Apache 2.2.8 (So I'm actually using require ldap-group), Subversion 1.4.6.
>
> Kevin R.
>
> "Adam Hubscher" <offbeatadam_at_gmail.com> wrote on 04/18/2008 12:00:48 PM:
>> Oops... I sent this to only one person. Forgot to hit reply to all. :)
>>
>> James, I thank you. You're a gentleman and a scholar. That was a
>> fantastic description of possibly the best way I could have considered
>> doing it. It hadn't dawned on me to use Apache's request based
>> security rather than attempting a patchwork authz based solution -
>> this provides a much more granular approach to security. In an
>> environment where compliance, SOX, PCI, et al... is becoming very
>> prominent, this will ensure that the appropriate permissions are
>> separated between contractors and full time employees appropriately.
>>
>> In regards to the performance question, there is a bell curve that you
>> have to look at when you are deploying this in a situation that would
>> truly warrant LDAP. For example...
>>
>> In my department, we have ~200 users that will use SVN exclusively as
>> part of their job on a daily basis. Further, there are ~400 or more
>> users that would use it for other tasks on a semi-frequent basis.
>>
>> Controlling this large group of SVN users is daunting. The time that
>> it would take to appropriately administer and generate the SVN ACLs
>> for these various locations would be nearing that 40-hour work day
>> that we all strive for. With LDAP, this administration overhead and
>> time is rendered near moot as all we have to do is maintain an LDAP
>> group - the permissions are permanent based on group.
>>
>> So, if you look at it this way - if the authentication performance is
>> based solely on the library itself and maintenance is not an issue -
>> SVN local authentication is going to be king. There is nothing that
>> hinders it. However, if you have a large group of people, and you have
>> a directory infrastructure (active directory, openLDAP, etc),
>> leveraging this will offset the overall performance loss of having to
>> traverse the network.
>>
>> In such an environment, the LDAP performance is seen with everything
>> else on a daily basis, so the overall login time is practically
>> meaningless. We already use LDAP on the apache login itself, we were
>> just using SVN ACLs prior and were looking for a more manageable
>> solution.
>>
>>
>> On Fri, Apr 18, 2008 at 10:22 AM, <kmradke_at_rockwellcollins.com> wrote:
>> > "James CE Johnson" <jcej_at_tragus.org> wrote on 04/18/2008 10:23:15 AM:
>> >
>> >
>> > > > On Fri, Apr 18, 2008 at 10:21 AM, James CE Johnson
> <jcej_at_tragus.org>
>> > > > wrote:
>> > > >> Hey Adam,
>> > > >>
>> > > >> This got a bit wordy as I was writing it up so I dumped it on
> my
>> > > >> too-often
>> > > >> neglected blog:
>> > > >>
>> > http://pteropus.blogspot.com/2008/04/securing-subversion-via-ldap.html
>> > > >
>> > > > Wow, that is detailed! Thanks for the post - I'm hoping to move
> our
>> > > > SVN authentication to LDAP this year and it would be terrific if
> I
>> > > > could move the authorization into LDAP as well. It means less
> work for
>> > > > me - I'm the SVN admin but someone else does LDAP :)
>> > >
>> > > Same here. In fact, I'm working with our group to figure out
> exactly how
>> > > we're going to manage (and hopefully delegate) the LDAP side of
> things.
>> > >
>> > > > 2 questions:
>> > > >
>> > > > 1) How is performance, as compared to using SVN's built-in Authz
>> > > > stuff? Faster? Slower? I know a lot of path-based checks can
> cause
>> > > > some operations to be slower.
>> > >
>> > > I haven't tested the two against one another. With LDAP's caching
> we can
>> > > take the lookup and network hits pretty much out of the picture. My
> gut
>> > > would say that the built-in stuff is probably faster *but* from
> past
>> > > experience I know that it inspects its auth file with every request
> --
>> > I'm
>> > > sure it doesn't read the file every time but it at least has to do
> a
>> > > timestamp check. LDAP integration is a fundamental requirement for
> us,
>> > > though, so the built-in was never an option.
>> > >
>> > > > 2) If you have a change to path access (which groups can access
> which
>> > > > paths), doesn't this require a restart of Apache?
>> > >
>> > > I believe so. That has always been my pattern of action. I will
> test any
>> > > changes in my dev zone then replicate that in production and bounce
> the
>> > > server off-hours. Now that you've made me think about it I'll have
> to go
>> > > test that again :-)
>> >
>> > httpd -k graceful
>> >
>> > or
>> >
>> > apachectl graceful
>> >
>> >
>> > is your friend...
>> >
>> > Kevin R.
>> >
>>
>>
>>
>> --
>> >>~OffbeatAdam~<<
>> "I'm not going there to die, I'm going to find out if I'm really
>> alive." - Spike, Cowboy Bebop
>
>
> ---------------------------------------------------------------------
> 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-18 20:35:05 CEST