Discussion:
svn commit failing - username not sent on the MERGE webdav command
g***@gregj.me
2017-08-03 21:07:42 UTC
Permalink
Hi,



Per the webpage - I am not a regular subscriber (yet) so please cc
'***@gregj.me' on any responses - thank you!



I am trying to implement path based authentication with webdav over http.
It looks like it is failing because there is no userid specified on the
webdav MERGE command when it attempts to finalize the commit.



Details.



In this case if my auth access file has:



[groups]

Svnadmins = gjohnson



[/ec-svn/branches/eCommerce/proto_3.x]

* = rw

@svnadmins = rw

@edi-dev = rw

@bldadmin = rw



I can commit a change as user 'gjohnson'. No problem.



However we don't want it wide open like this. If I remove the * = rw like
this:



[groups]

svnadmins = gjohnson



[/ec-svn/branches/eCommerce/proto_3.x]

@svnadmins = rw



(note my username (gjohnson) is a member of the svnadmins group so should
have rw access)



And attempt to commit a change I get: (Client Windows 2012 - subversion
1.9.5)



D:\src\svn\cedi>svn commit pom.xml

Sending pom.xml

Transmitting file data .done

Committing transaction...

svn: E175013: Commit failed (details follow):

svn: E175013: Access to
'/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi' forbidden

svn: E175013: Your commit message was left in a temporary file:

svn: E175013: 'D:\src\svn\cedi\svn-commit.4.tmp'



The same thing happens if I specify my userid directly:



[/ec-svn/branches/eCommerce/proto_3.x]

gjohnson = rw



If I look at the http transaction log I see the following sequence:



3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "OPTIONS
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi HTTP/1.1" 200 186 "-"
"SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "OPTIONS
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi HTTP/1.1" 200 97 "-"
"SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "POST /ec-svn/!svn/me
HTTP/1.1" 201 - "-" "SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "PROPPATCH
/ec-svn/!svn/txn/74220-1lbn HTTP/1.1" 207 430 "-" "SVN/1.9.5
(x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "HEAD
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi/testfile2.txt HTTP/1.1"
404 - "-" "SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "PUT
/ec-svn/!svn/txr/74220-1lbn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi/test
file2.txt HTTP/1.1" 201 404 "-" "SVN/1.9.5 (x64-microsoft-windows)
serf/1.3.9"

3.20.224.231 - - [03/Aug/2017:20:40:12 +0000] "MERGE
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi HTTP/1.1" 403 397 "-"
"SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "DELETE
/ec-svn/!svn/txn/74220-1lbn HTTP/1.1" 204 - "-" "SVN/1.9.5
(x64-microsoft-windows) serf/1.3.9"



This looks like it follows what I know (via google) from the protocol used.



Note that the MERGE line (line 7 - 2nd from the last) does *not* have a user
identified - others have '3.20.224.131 - gjohnson' but this has
'3.20.224.131 - -'. This seems to be the command that is failing. If the
auth file had '* = rw' it would pass - since a user is not required in that
instance.



Could this be the cause of the 'permission denied' and, if so, is there a
way to get subversion to send the username? (or any other way to fix it?).



Thank you - Greg
g***@gregj.me
2017-08-08 19:48:41 UTC
Permalink
Ok now I joined the mailing ilst. But I have not had any response to this
problem.



Any suggestions? Should I RTFM - if so which?



I've tried different things - and it only seems to allow access if
'anonymous' is given access. Which could be a deal breaker for us.



Ideas?



Thank you in advance :).



* Greg Johnson



From: ***@gregj.me [mailto:***@gregj.me]
Sent: Thursday, August 03, 2017 2:08 PM
To: '***@subversion.apache.org' <***@subversion.apache.org>
Subject: svn commit failing - username not sent on the MERGE webdav command



Hi,



Per the webpage - I am not a regular subscriber (yet) so please cc
'***@gregj.me' on any responses - thank you!



I am trying to implement path based authentication with webdav over http.
It looks like it is failing because there is no userid specified on the
webdav MERGE command when it attempts to finalize the commit.



Details.



In this case if my auth access file has:



[groups]

Svnadmins = gjohnson



[/ec-svn/branches/eCommerce/proto_3.x]

* = rw

@svnadmins = rw

@edi-dev = rw

@bldadmin = rw



I can commit a change as user 'gjohnson'. No problem.



However we don't want it wide open like this. If I remove the * = rw like
this:



[groups]

svnadmins = gjohnson



[/ec-svn/branches/eCommerce/proto_3.x]

@svnadmins = rw



(note my username (gjohnson) is a member of the svnadmins group so should
have rw access)



And attempt to commit a change I get: (Client Windows 2012 - subversion
1.9.5)



D:\src\svn\cedi>svn commit pom.xml

Sending pom.xml

Transmitting file data .done

Committing transaction...

svn: E175013: Commit failed (details follow):

svn: E175013: Access to
'/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi' forbidden

svn: E175013: Your commit message was left in a temporary file:

svn: E175013: 'D:\src\svn\cedi\svn-commit.4.tmp'



The same thing happens if I specify my userid directly:



[/ec-svn/branches/eCommerce/proto_3.x]

gjohnson = rw



If I look at the http transaction log I see the following sequence:



3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "OPTIONS
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi HTTP/1.1" 200 186 "-"
"SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "OPTIONS
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi HTTP/1.1" 200 97 "-"
"SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "POST /ec-svn/!svn/me
HTTP/1.1" 201 - "-" "SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "PROPPATCH
/ec-svn/!svn/txn/74220-1lbn HTTP/1.1" 207 430 "-" "SVN/1.9.5
(x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "HEAD
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi/testfile2.txt HTTP/1.1"
404 - "-" "SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "PUT
/ec-svn/!svn/txr/74220-1lbn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi/test
file2.txt HTTP/1.1" 201 404 "-" "SVN/1.9.5 (x64-microsoft-windows)
serf/1.3.9"

3.20.224.231 - - [03/Aug/2017:20:40:12 +0000] "MERGE
/ec-svn/branches/eCommerce/proto_3.x/9.9.8.3-4/cedi HTTP/1.1" 403 397 "-"
"SVN/1.9.5 (x64-microsoft-windows) serf/1.3.9"

3.20.224.231 - gjohnson [03/Aug/2017:20:40:12 +0000] "DELETE
/ec-svn/!svn/txn/74220-1lbn HTTP/1.1" 204 - "-" "SVN/1.9.5
(x64-microsoft-windows) serf/1.3.9"



This looks like it follows what I know (via google) from the protocol used.



Note that the MERGE line (line 7 - 2nd from the last) does *not* have a user
identified - others have '3.20.224.131 - gjohnson' but this has
'3.20.224.131 - -'. This seems to be the command that is failing. If the
auth file had '* = rw' it would pass - since a user is not required in that
instance.



Could this be the cause of the 'permission denied' and, if so, is there a
way to get subversion to send the username? (or any other way to fix it?).



Thank you - Greg
Philip Martin
2017-08-08 21:34:35 UTC
Permalink
Post by g***@gregj.me
Ok now I joined the mailing ilst. But I have not had any response to this
problem.
Any suggestions? Should I RTFM - if so which?
I've tried different things - and it only seems to allow access if
'anonymous' is given access. Which could be a deal breaker for us.
Ideas?
What you have posted of your authz file looks correct, but a complete,
self-contained, example would be better. What does the Location block
in your apache config file look like?
--
Philip
g***@gregj.me
2017-08-10 17:39:19 UTC
Permalink
Sorry for the late reply..

Our httpd.conf file contains for this location (some information retracted..
and some lines are commeted out)

## Main Subversion repository
<Location /ec-svn>
DAV svn
SVNPath "/usr/local/svn/ec-svn/repo"
ErrorDocument 404 default
AuthzSVNAccessFile "/usr/local/svn/ec-svn/auth/authaccess"
SVNIndexXSLT /xslt/default-svnindex.xsl
SVNPathAuthz off
#AuthzSVNAuthoritive off
#AuthUserFile /usr/local/svn/ec-svn/conf/htpasswd
AuthLDAPURL ldap://********
AuthLDAPBindDN "*****"
AuthLDAPBindPassword "*****"
AuthType Basic
AuthBasicProvider ldap
#AuthzLDAPAuthoritative on
AuthName " svn repository edisvn"
<LimitExcept MERGE>
Require valid-user
</LimitExcept>
</Location>




-----Original Message-----
From: Philip Martin [mailto:***@codematters.co.uk]
Sent: Tuesday, August 08, 2017 2:35 PM
To: ***@gregj.me
Cc: ***@subversion.apache.org
Subject: Re: svn commit failing - username not sent on the MERGE webdav
command
Post by g***@gregj.me
Ok now I joined the mailing ilst. But I have not had any response to
this problem.
Any suggestions? Should I RTFM - if so which?
I've tried different things - and it only seems to allow access if
'anonymous' is given access. Which could be a deal breaker for us.
Ideas?
What you have posted of your authz file looks correct, but a complete,
self-contained, example would be better. What does the Location block in
your apache config file look like?

--
Philip
Branko Čibej
2017-08-10 18:17:50 UTC
Permalink
Post by g***@gregj.me
Sorry for the late reply..
Our httpd.conf file contains for this location (some information retracted..
and some lines are commeted out)
## Main Subversion repository
<Location /ec-svn>
DAV svn
SVNPath "/usr/local/svn/ec-svn/repo"
ErrorDocument 404 default
AuthzSVNAccessFile "/usr/local/svn/ec-svn/auth/authaccess"
SVNIndexXSLT /xslt/default-svnindex.xsl
SVNPathAuthz off
#AuthzSVNAuthoritive off
#AuthUserFile /usr/local/svn/ec-svn/conf/htpasswd
AuthLDAPURL ldap://********
AuthLDAPBindDN "*****"
AuthLDAPBindPassword "*****"
AuthType Basic
AuthBasicProvider ldap
#AuthzLDAPAuthoritative on
AuthName " svn repository edisvn"
<LimitExcept MERGE>
Require valid-user
</LimitExcept>
</Location>
So you're telling httpd that MERGE requests do not need authentication.
Why then are you surprised when it doesn't provide the credentials to
mod_dav_svn?

-- Brane
Branko Čibej
2017-08-10 18:22:19 UTC
Permalink
Post by Branko Čibej
Post by g***@gregj.me
Sorry for the late reply..
Our httpd.conf file contains for this location (some information retracted..
and some lines are commeted out)
## Main Subversion repository
<Location /ec-svn>
DAV svn
SVNPath "/usr/local/svn/ec-svn/repo"
ErrorDocument 404 default
AuthzSVNAccessFile "/usr/local/svn/ec-svn/auth/authaccess"
SVNIndexXSLT /xslt/default-svnindex.xsl
SVNPathAuthz off
#AuthzSVNAuthoritive off
#AuthUserFile /usr/local/svn/ec-svn/conf/htpasswd
AuthLDAPURL ldap://********
AuthLDAPBindDN "*****"
AuthLDAPBindPassword "*****"
AuthType Basic
AuthBasicProvider ldap
#AuthzLDAPAuthoritative on
AuthName " svn repository edisvn"
<LimitExcept MERGE>
Require valid-user
</LimitExcept>
</Location>
So you're telling httpd that MERGE requests do not need authentication.
Why then are you surprised when it doesn't provide the credentials to
mod_dav_svn?
Sorry, to mod_authz_svn, not mod_dav_svn.

-- Brane
g***@gregj.me
2017-08-10 21:12:10 UTC
Permalink
Ok I think this is onto something. I changed

<LimitExcept MERGE> to <LimitExcept GET> and the commit worked. When I removed the LIMITEXCEPT completely it didn't even request my password (and failed).

I'll have our tester test it with that tonight if possible.

Thank You!

Question: What *should* be specified?

-----Original Message-----
From: Branko Čibej [mailto:***@apache.org]
Sent: Thursday, August 10, 2017 11:18 AM
To: ***@subversion.apache.org
Subject: Re: svn commit failing - username not sent on the MERGE webdav command
Post by g***@gregj.me
Sorry for the late reply..
Our httpd.conf file contains for this location (some information retracted..
and some lines are commeted out)
## Main Subversion repository
<Location /ec-svn>
DAV svn
SVNPath "/usr/local/svn/ec-svn/repo"
ErrorDocument 404 default
AuthzSVNAccessFile "/usr/local/svn/ec-svn/auth/authaccess"
SVNIndexXSLT /xslt/default-svnindex.xsl
SVNPathAuthz off
#AuthzSVNAuthoritive off
#AuthUserFile /usr/local/svn/ec-svn/conf/htpasswd
AuthLDAPURL ldap://********
AuthLDAPBindDN "*****"
AuthLDAPBindPassword "*****"
AuthType Basic
AuthBasicProvider ldap
#AuthzLDAPAuthoritative on
AuthName " svn repository edisvn"
<LimitExcept MERGE>
Require valid-user
</LimitExcept>
</Location>
So you're telling httpd that MERGE requests do not need authentication.
Why then are you surprised when it doesn't provide the credentials to mod_dav_svn?

-- Brane
Branko Čibej
2017-08-11 11:16:21 UTC
Permalink
Post by g***@gregj.me
Ok I think this is onto something. I changed
<LimitExcept MERGE> to <LimitExcept GET> and the commit worked. When I removed the LIMITEXCEPT completely it didn't even request my password (and failed).
I'll have our tester test it with that tonight if possible.
Thank You!
Question: What *should* be specified?
If you want all access to be authenticated, you do not need a <Limit> or
<LimitExcept> clause; just the "Require valid-user".

You'd use Limit(Except) in order to impose read-only and read-write
distinction in the request level, before mod_authz_svn kicks in. Here's
an example, the config I use at $DAYJOB for httpd 2.4.x:

<RequireAll>
Require valid-user
<Limit HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
Require ldap-group cn=dev,ou=group,dc=example,dc=com
Require ldap-group cn=dev.readonly,ou=group,dc=example,dc=com
# More reader groups here
</RequireAny>
</Limit>
<LimitExcept HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
Require ldap-group cn=dev,ou=group,dc=example,dc=com
# More writer groups here
</RequireAny>
</LimitExcept>
</RequireAll>


I have LDAP authentication set up, and group assignments in LDAP to
distinguish between users with only read access and users with
read/write access. Notice how I use Limit and LimitExcept so that the
list of request methods is the same in both clauses, makes it easy to
check the config by eye and I only have to remember what the "read
access" methods are. :)


-- Brane

Loading...