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:
Require group CN=In_This_One,...
Require group CN=Not_For_Me,...
If I "checkout" /kmr_test, I get the contents of private, even
without being in the group.
Am I missing something?
Apache 2.2.8 (So I'm actually using require ldap-group), Subversion 1.4.6.
"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
> 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
> > > > wrote:
> > > >> Hey Adam,
> > > >>
> > > >> This got a bit wordy as I was writing it up so I dumped it on
> > > >> 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
> > > > SVN authentication to LDAP this year and it would be terrific if
> > > > could move the authorization into LDAP as well. It means less
> > > > me - I'm the SVN admin but someone else does LDAP :)
> > >
> > > Same here. In fact, I'm working with our group to figure out
> > > we're going to manage (and hopefully delegate) the LDAP side of
> > >
> > > > 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
> > > > some operations to be slower.
> > >
> > > I haven't tested the two against one another. With LDAP's caching
> > > take the lookup and network hits pretty much out of the picture. My
> > > would say that the built-in stuff is probably faster *but* from
> > > 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
> > > timestamp check. LDAP integration is a fundamental requirement for
> > > though, so the built-in was never an option.
> > >
> > > > 2) If you have a change to path access (which groups can access
> > > > paths), doesn't this require a restart of Apache?
> > >
> > > I believe so. That has always been my pattern of action. I will
> > > changes in my dev zone then replicate that in production and bounce
> > > server off-hours. Now that you've made me think about it I'll have
> > > test that again :-)
> > httpd -k graceful
> > or
> > apachectl graceful
> > is your friend...
> > Kevin R.
> "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
Received on 2008-04-18 19:49:04 CEST