Thanks for the information.
I have implemented a reasonable, although not ideal, solution whereby we
use mod_authz_ldap to authenticate the user upstream of any Subversion
actions requiring authorization and then mod_authz_svn to authorize the
user against group membership.
On Red Hat Enterprise 3, the details involve removing the "standard"
0.22 version mod_authz_ldap RPM and installing the 0.26 version from the
Internet. Prior to 0.26, mod_authz_ldap reported the "user" as the full
LDAP DN (ie uid=username,ou=org,dc=company,dc=com) which of course is
not compatible with mod_authz_svn due to its commas.
Once the update mod_authz_ldap package was installed, we had the user
being reported as simply "user". We then used mod_authz_svn's access
file to control permissions. The less than ideal part is that while we
authenticate off LDAP, we authorize off a local access file. We have
helped make this a better picture by using group names in
mod_authz_svn's authorization file that are the same as our LDAP group
names. Further we are using a Perl script to look at what groups the
mod_authz_svn file is using, and then check group membership for them
against LDAP, applying any updates from LDAP to the mod_authz_svn access
file. This, we then schedule to run at some interval to ensure the SVN
access file group membership is reasonably synchronized with the LDAP
group membership.
I figured others would be interested to know the work-around I put in place.
FYI, the updated Apache config only has a single Location section for
the /svn/main URI and after the LDAP group config, we do something like
the following:
<Location /svn/main>
DAV svn
SVNPath /shared/subversion/repos/main
# ... more LDAP config snipped for brevity ...
AuthzLDAPGroupScope base
AuthzLDAPMemberKey uniquemember
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
AuthzSVNAccessFile /path/to/access/file
</Location>
- Brian
Erik Huelsmann wrote:
> [SNIP]
>
>> The issue is that while we can see the basic auth username for the
>> transaction in the apache access log, this username is not being
>> populated as the author. This of course results in us seeing no author
>> when looking at the resulting repository (via log, info, etc).
>>
>> Here is the Apache configuration (from subversion.conf):
>>
>> === BEGIN subversion.conf
>> LoadModule authz_ldap_module modules/mod_authz_ldap.so
>> LoadModule dav_svn_module modules/mod_dav_svn.so
>> LoadModule authz_svn_module modules/mod_authz_svn.so
>>
>> # Main Repository
>> <Location /svn/main>
>> DAV svn
>> SVNPath /shared/subversion/repos/main
>> SVNIndexXSLT "/svnindex.xsl"
>> SSLRequireSSL
>> # ldap lookup
>> AuthzLDAPEngine on
>> AuthType Basic
>> AuthName "LDAP"
>> AuthzLDAPServer 127.0.0.1:10636
>> AuthzLDAPLogLevel warn
>> # user lookup
>> AuthzLDAPUserBase cn=users,ou=org,dc=abc,dc=com
>> AuthzLDAPUserKey uid
>> AuthzLDAPUserScope base
>> # group lookup
>> AuthzLDAPGroupBase cn=groups,ou=org,dc=abc,dc=com
>> AuthzLDAPGroupKey cn
>> AuthzLDAPGroupScope base
>> AuthzLDAPMemberKey uniquemember
>> </Location>
>>
>> # Protect root level directories - deny write
>> <LocationMatch "/svn/main$">
>> <LimitExcept GET PROPFIND OPTIONS REPORT>
>> Deny from all
>> </LimitExcept>
>> </LocationMatch>
>> # under root are three subdirs for organization purposes
>> # allow only admins to write to these
>> <LocationMatch
>> "/svn/main/(Common|Investor.*Services|Securities.*Services)$">
>> <LimitExcept GET PROPFIND OPTIONS REPORT>
>> require group "SVN Administrator"
>> </LimitExcept>
>> </LocationMatch>
>
>
>> Prior to posting this message I did search through previous messages on
>> this list as well as read through the FAQ. While I did find similar
>> issues, it seemed that they all referenced the issue being tied to
>> anonymous write access. Our repository is not configured for anonymous
>> write (accomplished by the <LimitExcept .... /> within the
>> subversion.conf file and evident in that modify operations do prompt the
>> subversion client for username and password).
>
>
> Your access control isn't correctly set up: the *only* way to get
> access control set up correctly in conjuction with WebDAV is to use
> mod_svn_authz. Using LocationMatch or other - similar - constructs
> won't work.
>
> If the problem is that you can't use mod_svn_authz because it doesn't
> do wildcards or regexes, then I'd like to point you to the following
> patch which does provide that functionality (I posted about that
> earlier this week in relation to LOCK requests failing):
>
> http://svn.haxx.se/dev/archive-2005-02/0631.shtml
>
>
>
>> As you can see in the log excerpt above, user123 is identified with the
>> MERGE method that occurs as part of this transaction. Yet, there is no
>> resulting author entry:
>
>
> Yes, but none of MKACTIVITY, MKCOL, REPORT or CHECKOUT are
> authenticated... At least the authentication data for mod_dav_svn is
> rather minimal.
>
>> svn info "https://server.abc.net/svn/main/Securities Services"
>> Path: Securities Services
>> URL: https://server.abc.net/svn/main/Securities%20Services
>> Repository Root: https://server.abc.net/svn/main
>> Repository UUID: 6947a9cc-020e-0410-bd0f-a223dbb24b38
>> Revision: 6535
>> Node Kind: directory
>> Last Changed Rev: 6535
>> Last Changed Date: 2006-06-29 21:43:18 -0400 (Thu, 29 Jun 2006)
>>
>>
>> I would appreciate any help/insight into this issue. I am hoping it is
>> a configuration or other easily-corrected oversight; yet, I have already
>> considered the possibility of having to write something to grab the
>> remote user and throw it into the svn:author property if absolutely
>> necessary.
>
>
> Fixing your configuration would be my advise. If you have time to
> address the comments of Branko Cibej on the patch in the link I
> referred you to above, this functionality has - IMO - quite a big
> chance of being incorporated in mod_authz_svn.
>
> HTH,
>
>
> Erik.
>
> ---------------------------------------------------------------------
> 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
Received on Wed Jul 12 12:51:45 2006