You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Brian Brophy <br...@email.com> on 2006/06/30 01:57:57 UTC
Apache mod_dav_svn Issue: no author
Hello,
We have an existing Subversion environment that is as follows:
- Red Hat Enterprise 3 (update 6)
- Apache 2.0.46.54
- Subversion 1.2.1
We are using mod_dav_svn to access Subversion through Apache (over
SSL). The user store for authentication and authorization is LDAP (via
module authz_ldap_module which is mod_authz_ldap.so).
Authentication and authorization work as expected. Users are
authenticated against their LDAP password and the ability to "modify"
Subversion requires membership in a designated LDAP group. Note,
anonymous or unauthenticated access is available for "read" operations.
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>
# Project Subversion - clients, docs, etc
<LocationMatch "/svn/main/Common/Subversion.+">
<LimitExcept GET PROPFIND OPTIONS REPORT>
require group "SVN Administrator"
</LimitExcept>
</LocationMatch>
# Project Architecture
<LocationMatch "/svn/main/Common/Architecture.+">
<LimitExcept GET PROPFIND OPTIONS REPORT>
require group "SVN Architecture"
</LimitExcept>
</LocationMatch>
=== END subversion.conf
A sample transaction would be to create a new folder in one of the
"projects":
- Using TortoiseSVN (1.3.x) browse the repository and create folder
under /svn/main/Common/Securities Services
This results in the following Apache access log entries:
== BEGIN access log
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/Securities%20Services/Test HTTP/1.1" 207 726
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 401
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/bln/6524 HTTP/1.1" 207 458
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/Securities%20Services/Test HTTP/1.1" 207 726
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 401
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/bln/6524 HTTP/1.1" 207 458
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/Securities%20Services/Test HTTP/1.1" 207 726
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 401
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/bln/6524 HTTP/1.1" 207 458
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/Securities%20Services/Test HTTP/1.1" 207 726
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 458
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/bc/6524/Securities%20Services/Test HTTP/1.1" 207 739
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/Securities%20Services/Test HTTP/1.1" 207 726
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 458
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "PROPFIND
/svn/main/!svn/bc/6524/Securities%20Services/Test HTTP/1.1" 207 1293
10.55.144.102 - - [29/Jun/2006:13:42:51 -0400] "REPORT
https://server.abc.net/svn/main/Securities%20Services/Test HTTP/1.1" 200 112
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "OPTIONS
/svn/main/Securities%20Services HTTP/1.1" 200 188
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "MKACTIVITY
/svn/main/!svn/act/6b278b93-b8f0-d743-9b9a-a3a7c9beb782 HTTP/1.1" 201 227
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "PROPFIND
/svn/main/Securities%20Services HTTP/1.1" 207 454
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 401
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "CHECKOUT
/svn/main/!svn/bln/6524 HTTP/1.1" 201 244
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "PROPPATCH
/svn/main/!svn/wbl/6b278b93-b8f0-d743-9b9a-a3a7c9beb782/6524 HTTP/1.1"
207 356
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "PROPFIND
/svn/main/Securities%20Services HTTP/1.1" 207 429
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "CHECKOUT
/svn/main/!svn/ver/6524/Securities%20Services HTTP/1.1" 201 261
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "MKCOL
/svn/main/!svn/wrk/6b278b93-b8f0-d743-9b9a-a3a7c9beb782/Securities%20Services/2
HTTP/1.1" 201 251
10.55.144.102 - - [29/Jun/2006:13:43:00 -0400] "MERGE
/svn/main/Securities%20Services HTTP/1.1" 401 401
10.55.144.102 - uid=user123,cn=users,ou=org,dc=abc,dc=com
[29/Jun/2006:13:43:00 -0400] "MERGE /svn/main/Securities%20Services
HTTP/1.1" 200 425
10.55.144.102 - - [29/Jun/2006:13:43:01 -0400] "DELETE
/svn/main/!svn/act/6b278b93-b8f0-d743-9b9a-a3a7c9beb782 HTTP/1.1" 204 -
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/Securities%20Services/2 HTTP/1.1" 207 720
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 401
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/!svn/bln/6525 HTTP/1.1" 207 458
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/Securities%20Services/2 HTTP/1.1" 207 720
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 401
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/!svn/bln/6525 HTTP/1.1" 207 458
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/Securities%20Services/2 HTTP/1.1" 207 720
10.55.144.102 - - [29/Jun/2006:13:43:04 -0400] "PROPFIND
/svn/main/!svn/vcc/default HTTP/1.1" 207 458
=== END access.log
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).
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:
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.
Thanks,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Apache mod_dav_svn Issue: no author
Posted by Brian Brophy <br...@email.com>.
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
Re: Apache mod_dav_svn Issue: no author
Posted by Erik Huelsmann <eh...@gmail.com>.
[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