You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by James CE Johnson <jc...@tragus.org> on 2008/04/17 20:55:09 UTC
Re: [SVN] SVN and LDAP
Hi Adam,
I'm doing exactly this here in my corner of the world. Unfortunately, I'm
running out the door at the moment. I will try to post something of the
details for you tomorrow.
James
> Hey Everyone,
>
> I have successfully had svn, apache, and webdav utilize LDAP for
> authentication...
>
> My issue, is that I would like to have the ACL depend on LDAP as well.
> We have groups defined in the directory that would not only make the
> ACL easy to administer, but also make it cleaner and more legible.
>
> We have upwards of about 50 to 60 users spread across a number of
> groups, which makes the ACL rather large and dissociative.
>
> Is there any way to have it depend on LDAP groups for access controls?
>
> I have searched and seen a few threads in the mailing list related to
> this, but they are all ~1yr or older, and was hoping to see if there
> were any creative solutions to this.
>
> OffbeatAdam
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [SVN] Re: SVN and LDAP
Posted by km...@rockwellcollins.com.
"James CE Johnson" <jc...@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 really hope it works and I'm doing something stupid, because we are in
the need to roll out per directory access control to 2000+ users...
I was planning on setting up some administrative web pages to manage
authz access files that were periodically exported from ldap and
REALLY want something simpler...
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN and LDAP
Posted by James CE Johnson <jc...@tragus.org>.
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" <jc...@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@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [SVN] Re: [SVN] Re: SVN and LDAP
Posted by Adam Hubscher <of...@gmail.com>.
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" <jc...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [SVN] Re: [SVN] Re: SVN and LDAP
Posted by James CE Johnson <jc...@tragus.org>.
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" <jc...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [SVN] Re: SVN and LDAP
Posted by km...@rockwellcollins.com.
"James CE Johnson" <jc...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [SVN] Re: SVN and LDAP
Posted by James CE Johnson <jc...@tragus.org>.
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.
> 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, <km...@rockwellcollins.com> wrote:
>> "James CE Johnson" <jc...@tragus.org> wrote on 04/18/2008 10:23:15 AM:
>>
>>
>> > > On Fri, Apr 18, 2008 at 10:21 AM, James CE Johnson <jc...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN and LDAP
Posted by km...@rockwellcollins.com.
"James CE Johnson" <jc...@tragus.org> wrote on 04/18/2008 10:23:15 AM:
> > On Fri, Apr 18, 2008 at 10:21 AM, James CE Johnson <jc...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN and LDAP
Posted by James CE Johnson <jc...@tragus.org>.
> On Fri, Apr 18, 2008 at 10:21 AM, James CE Johnson <jc...@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 :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN and LDAP
Posted by Andy Levy <an...@gmail.com>.
On Fri, Apr 18, 2008 at 10:21 AM, James CE Johnson <jc...@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 :)
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.
2) If you have a change to path access (which groups can access which
paths), doesn't this require a restart of Apache?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [SVN] Re: SVN and LDAP
Posted by James CE Johnson <jc...@tragus.org>.
> "James CE Johnson" <jc...@tragus.org> wrote on 04/18/2008 09:21:33 AM:
>> 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
>>
>> Let me know if you have trouble getting to it (corporate firewalls and
> all
>> that). If so, I will go ahead and post it all here.
>
> Nice write-up. I swear I tried something similar in the past and I
> was able to "get around" my sub directory apache permissions by
> just doing a checkout at a higher level. I'll have to retest.
> (I didn't think the client used full sub paths when doing a
> recursive checkout, so the potentially more restrictive apache
> location checks never get called in this case.)
>
>
> Any reason you chose to use the longer list of "write" options
> in the limit/limitexcept pair instead of swapping them like this:
>
> # These groups have write access
> <LimitExcept GET PROPFIND OPTIONS REPORT>
> Require group CN=groupa-rw,...
> </LimitExcept>
> # These groups have read access
> <Limit GET PROPFIND OPTIONS REPORT>
> Require group CN=groupa-rw,...
> Require group CN=groupb-ro,...
> </Limit>
No particular reason. I sorted out the list by trial and error so what you
see is what made sense at the time. I'm sure that anyone with a deeper SVN
knowledge (and that's a *huge* population!) will know a more efficient way
to do it. It has been a few months since I set it all up but I think my
thought process was to get the simple case working (without
Limit/LimitExcept) and then to block write access. So as I watched the
logs I saw the MERGE/MKCOL/etc... come across and worked out the syntax to
prevent them via Limit. Once I had that, doing the final case with both
Limit and LimitExcept sort of worked itself out.
>
> Kevin R.
>
>> > Thank you very much james. I look forward to your solution. I've found
>> > a little bit of a solution from Mandriva where they modify the
>> > svn_perms.py file, however as I'm not 100% familiar with the
>> > additional python tools I'm not 100% sure on how to implement this
>> > myself in an ubuntu environment.
>> >
>> > The other issue that I have with it is, as this is an enterprise
>> > environment, that sort of customization would prefer to be avoided,
>> > however I understand that in this particular situation such may be
>> > required, and I am not avoiding it 100%.
>> >
>> > Thanks for your future reply :)
>> >
>> > 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 17, 2008, at 3:55 PM, James CE Johnson wrote:
>> >> Hi Adam,
>> >>
>> >> I'm doing exactly this here in my corner of the world.
>> >> Unfortunately, I'm
>> >> running out the door at the moment. I will try to post something of
>> >> the
>> >> details for you tomorrow.
>> >>
>> >> James
>> >>
>> >>> Hey Everyone,
>> >>>
>> >>> I have successfully had svn, apache, and webdav utilize LDAP for
>> >>> authentication...
>> >>>
>> >>> My issue, is that I would like to have the ACL depend on LDAP as
>> >>> well.
>> >>> We have groups defined in the directory that would not only make the
>> >>> ACL easy to administer, but also make it cleaner and more legible.
>> >>>
>> >>> We have upwards of about 50 to 60 users spread across a number of
>> >>> groups, which makes the ACL rather large and dissociative.
>> >>>
>> >>> Is there any way to have it depend on LDAP groups for access
>> >>> controls?
>> >>>
>> >>> I have searched and seen a few threads in the mailing list related
> to
>> >>> this, but they are all ~1yr or older, and was hoping to see if there
>> >>> were any creative solutions to this.
>> >>>
>> >>> OffbeatAdam
>> >>
>> >>
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN and LDAP
Posted by km...@rockwellcollins.com.
"James CE Johnson" <jc...@tragus.org> wrote on 04/18/2008 09:21:33 AM:
> 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
>
> Let me know if you have trouble getting to it (corporate firewalls and
all
> that). If so, I will go ahead and post it all here.
Nice write-up. I swear I tried something similar in the past and I
was able to "get around" my sub directory apache permissions by
just doing a checkout at a higher level. I'll have to retest.
(I didn't think the client used full sub paths when doing a
recursive checkout, so the potentially more restrictive apache
location checks never get called in this case.)
Any reason you chose to use the longer list of "write" options
in the limit/limitexcept pair instead of swapping them like this:
# These groups have write access
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require group CN=groupa-rw,...
</LimitExcept>
# These groups have read access
<Limit GET PROPFIND OPTIONS REPORT>
Require group CN=groupa-rw,...
Require group CN=groupb-ro,...
</Limit>
Kevin R.
> > Thank you very much james. I look forward to your solution. I've found
> > a little bit of a solution from Mandriva where they modify the
> > svn_perms.py file, however as I'm not 100% familiar with the
> > additional python tools I'm not 100% sure on how to implement this
> > myself in an ubuntu environment.
> >
> > The other issue that I have with it is, as this is an enterprise
> > environment, that sort of customization would prefer to be avoided,
> > however I understand that in this particular situation such may be
> > required, and I am not avoiding it 100%.
> >
> > Thanks for your future reply :)
> >
> > 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 17, 2008, at 3:55 PM, James CE Johnson wrote:
> >> Hi Adam,
> >>
> >> I'm doing exactly this here in my corner of the world.
> >> Unfortunately, I'm
> >> running out the door at the moment. I will try to post something of
> >> the
> >> details for you tomorrow.
> >>
> >> James
> >>
> >>> Hey Everyone,
> >>>
> >>> I have successfully had svn, apache, and webdav utilize LDAP for
> >>> authentication...
> >>>
> >>> My issue, is that I would like to have the ACL depend on LDAP as
> >>> well.
> >>> We have groups defined in the directory that would not only make the
> >>> ACL easy to administer, but also make it cleaner and more legible.
> >>>
> >>> We have upwards of about 50 to 60 users spread across a number of
> >>> groups, which makes the ACL rather large and dissociative.
> >>>
> >>> Is there any way to have it depend on LDAP groups for access
> >>> controls?
> >>>
> >>> I have searched and seen a few threads in the mailing list related
to
> >>> this, but they are all ~1yr or older, and was hoping to see if there
> >>> were any creative solutions to this.
> >>>
> >>> OffbeatAdam
> >>
> >>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN and LDAP
Posted by James CE Johnson <jc...@tragus.org>.
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
Let me know if you have trouble getting to it (corporate firewalls and all
that). If so, I will go ahead and post it all here.
Hope this helps,
james
> Thank you very much james. I look forward to your solution. I've found
> a little bit of a solution from Mandriva where they modify the
> svn_perms.py file, however as I'm not 100% familiar with the
> additional python tools I'm not 100% sure on how to implement this
> myself in an ubuntu environment.
>
> The other issue that I have with it is, as this is an enterprise
> environment, that sort of customization would prefer to be avoided,
> however I understand that in this particular situation such may be
> required, and I am not avoiding it 100%.
>
> Thanks for your future reply :)
>
> 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 17, 2008, at 3:55 PM, James CE Johnson wrote:
>> Hi Adam,
>>
>> I'm doing exactly this here in my corner of the world.
>> Unfortunately, I'm
>> running out the door at the moment. I will try to post something of
>> the
>> details for you tomorrow.
>>
>> James
>>
>>> Hey Everyone,
>>>
>>> I have successfully had svn, apache, and webdav utilize LDAP for
>>> authentication...
>>>
>>> My issue, is that I would like to have the ACL depend on LDAP as
>>> well.
>>> We have groups defined in the directory that would not only make the
>>> ACL easy to administer, but also make it cleaner and more legible.
>>>
>>> We have upwards of about 50 to 60 users spread across a number of
>>> groups, which makes the ACL rather large and dissociative.
>>>
>>> Is there any way to have it depend on LDAP groups for access
>>> controls?
>>>
>>> I have searched and seen a few threads in the mailing list related to
>>> this, but they are all ~1yr or older, and was hoping to see if there
>>> were any creative solutions to this.
>>>
>>> OffbeatAdam
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [SVN] SVN and LDAP
Posted by Adam Hubscher <of...@gmail.com>.
Thank you very much james. I look forward to your solution. I've found
a little bit of a solution from Mandriva where they modify the
svn_perms.py file, however as I'm not 100% familiar with the
additional python tools I'm not 100% sure on how to implement this
myself in an ubuntu environment.
The other issue that I have with it is, as this is an enterprise
environment, that sort of customization would prefer to be avoided,
however I understand that in this particular situation such may be
required, and I am not avoiding it 100%.
Thanks for your future reply :)
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 17, 2008, at 3:55 PM, James CE Johnson wrote:
> Hi Adam,
>
> I'm doing exactly this here in my corner of the world.
> Unfortunately, I'm
> running out the door at the moment. I will try to post something of
> the
> details for you tomorrow.
>
> James
>
>> Hey Everyone,
>>
>> I have successfully had svn, apache, and webdav utilize LDAP for
>> authentication...
>>
>> My issue, is that I would like to have the ACL depend on LDAP as
>> well.
>> We have groups defined in the directory that would not only make the
>> ACL easy to administer, but also make it cleaner and more legible.
>>
>> We have upwards of about 50 to 60 users spread across a number of
>> groups, which makes the ACL rather large and dissociative.
>>
>> Is there any way to have it depend on LDAP groups for access
>> controls?
>>
>> I have searched and seen a few threads in the mailing list related to
>> this, but they are all ~1yr or older, and was hoping to see if there
>> were any creative solutions to this.
>>
>> OffbeatAdam
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org