> "James CE Johnson" <jcej_at_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_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:23:04 CEST