Discussion:
Problem with authorized user and SVN access
Stefan Hauffe
2018-01-22 11:39:26 UTC
Permalink
Hello,

I refined my mail from 05/01/2017 and now I think there is a bug in the mod_authz_svn Module. This may allow users to see content for which they aren't allowed for.

For the general setup, I have an Apache 2.4, Subversion 1.9 modules and mod_lua activated for authentification. The LUA-hook works for none-SVN-Locations, my user is authorized. The httpd.conf and LUA script is attached below.

Case 1:
- The accessfile configures my user to have access on repo-root:
[repo:/]
myuser = rw
- The client (curl) shows me the repo-root but none of the files below.
- The error_log shows, that my user got authorized on root:
[Fri Jan 19 21:20:58.735108 2018] [authz_svn:info] [pid 3465:tid 140589093869312] [client ::1:59812] Access granted: 'myuser' GET (null)
- But I'm not allowed to see a file below:
[Fri Jan 19 21:20:58.735706 2018] [authz_svn:info] [pid 3465:tid 140589093869312] [client ::1:59812] Access denied: - GET repo:/muhmiau.txt

Case 2:
- The accessfile configures everybody to have access on repo-root:
[repo:/]
* = rw
- The client (curl) shows me a repo-root and the files below.
- The error-log tells, that my user is allowed to see the root and the file:
[Fri Jan 19 21:26:03.803831 2018] [authz_svn:info] [pid 3425:tid 140589085476608] [client ::1:59814] Access granted: 'myuser' GET (null)
[Fri Jan 19 21:26:03.806508 2018] [authz_svn:info] [pid 3425:tid 140589085476608] [client ::1:59814] Access granted: 'myuser' GET repo:/muhmiau.txt

Case 3:
- Now I have an accessfile, which allows everyone to rw, *but not my user*:
[repo:/]
* = rw
myuser =
- The client (curl) shows me the full repo content
- The error_log tells, that my user is allowed to see the root and the file:
[Fri Jan 19 21:29:57.383442 2018] [authz_svn:info] [pid 3426:tid 140589085476608] [client ::1:59816] Access granted: 'myuser' GET (null)
[Fri Jan 19 21:29:57.385402 2018] [authz_svn:info] [pid 3426:tid 140589085476608] [client ::1:59816] Access granted: - GET repo:/muhmiau.txt

That raised several questions:
1. Why is my user not "known" for a special file in Case 1, when it generally works? (Case 2)
2. Why does the restriction of a right (Case 3) does not lead to a restricted view? As you can see in the log, the user is not known (like Case 1).

For me, especially Case 3 looks suspicious.

Any help would be appreciated.

Thanks and Kind Regards,
Stefan


PS - Configuration

So this is my repo-configuration:
<Location /svn/repo>
DAV svn
SVNPath "/.../repo"
LuaHookCheckUserID "/etc/apache2/lua/hook.lua" authcheck_hook
AuthzSVNAccessFile "/.../repo.access"
Require valid-user
</Location>

As you can see, the authorization is done by the Lua-script. The hook.lua accepts every request by setting a "myuser" on the request-entity:

require 'apache2'
function authcheck_hook(r)
r.user = "myuser"
return apache2.OK
end

In every case, I call the webserver with a simple curl-Command: "curl http://localhost:4402/svn/repo"


-----Ursprüngliche Nachricht-----
Von: Branko Čibej [mailto:***@apache.org]
Gesendet: Freitag, 5. Januar 2018 16:30
An: ***@subversion.apache.org
Betreff: Re: Apache SVN module and LUA authentification hook
Hello community,
 
I have an Apache 2.4 which shall deliver SVN repos by the
http-Protocol. I’m experienced with standard Basic Authentification
and path-based authorization for the Subversion repo.
 
In my new application, the authentication will be done by a LUA-script
using the directive “LuaHookCheckUserID”. Generally, the LUA script
works as expected (used this documentation
<https://httpd.apache.org/docs/trunk/mod/mod_lua.html#luahookcheckuserid>).
 
Unfortunately it seems, that the authorization file (Subversion
Accessfile) is not read out correctly. I see an empty repo with my
(authorized) user.
 
From the logfile (Debug/Error) I see, that LUA granted my user. But
 
Accepted user myuser
[authz_svn:info] [pid 6872:tid ] [client ip] Access granted: 'myuser'
GET (null)
[authz_svn:debug] [pid 6872:tid ]
subversion/mod_authz_svn/mod_authz_svn.c(450): [client ip] Path to
authz file is /path/to/accessfile
[authz_svn:info] [pid 6872:tid ] [client ip] Access denied: - GET
repo002:/file.txt
 
 
require 'apache2'
function authcheck_hook(r)
    r.user = "myuser"
    r:debug("Accepted user " .. r.user)
    return apache2.OK
end
Are you really changing the username stored in the request in your authentication script? That could certainly be the problem, AFAIK there's no guarantee that that change gets propagated back to mod_authz_svn.

(It's also a horribly wrong approach to auth
Stefan Sperling
2018-01-22 12:09:45 UTC
Permalink
Post by Stefan Hauffe
Hello,
I refined my mail from 05/01/2017 and now I think there is a bug in the mod_authz_svn Module. This may allow users to see content for which they aren't allowed for.
For the general setup, I have an Apache 2.4, Subversion 1.9 modules and mod_lua activated for authentification. The LUA-hook works for none-SVN-Locations, my user is authorized. The httpd.conf and LUA script is attached below.
[repo:/]
myuser = rw
- The client (curl) shows me the repo-root but none of the files below.
[Fri Jan 19 21:20:58.735108 2018] [authz_svn:info] [pid 3465:tid 140589093869312] [client ::1:59812] Access granted: 'myuser' GET (null)
[Fri Jan 19 21:20:58.735706 2018] [authz_svn:info] [pid 3465:tid 140589093869312] [client ::1:59812] Access denied: - GET repo:/muhmiau.txt
[repo:/]
* = rw
- The client (curl) shows me a repo-root and the files below.
[Fri Jan 19 21:26:03.803831 2018] [authz_svn:info] [pid 3425:tid 140589085476608] [client ::1:59814] Access granted: 'myuser' GET (null)
[Fri Jan 19 21:26:03.806508 2018] [authz_svn:info] [pid 3425:tid 140589085476608] [client ::1:59814] Access granted: 'myuser' GET repo:/muhmiau.txt
[repo:/]
* = rw
myuser =
- The client (curl) shows me the full repo content
[Fri Jan 19 21:29:57.383442 2018] [authz_svn:info] [pid 3426:tid 140589085476608] [client ::1:59816] Access granted: 'myuser' GET (null)
[Fri Jan 19 21:29:57.385402 2018] [authz_svn:info] [pid 3426:tid 140589085476608] [client ::1:59816] Access granted: - GET repo:/muhmiau.txt
1. Why is my user not "known" for a special file in Case 1, when it generally works? (Case 2)
2. Why does the restriction of a right (Case 3) does not lead to a restricted view? As you can see in the log, the user is not known (like Case 1).
For me, especially Case 3 looks suspicious.
Any help would be appreciated.
This is a common misunderstanding. The behaviour looks strange but it is
the result of the fact that per-path permissions in authz rule sets are
combined in a logical OR fashion, rather than logical AND.

Your interpretation of what your ruleset number 3 means assumes logical AND.
In fact, access to the path / is granted because 'myuser' is matched by '*':

[repo:/]
* = rw # grant access to anyone
myuser = # OR don't provide access to this user (has no effect)

This is hinted at in the svnbook at
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html#svn.serverconfig.pathbasedauthz.groups

"Another important fact is that group permissions are not overridden by
individual user permissions. Rather, the combination of all matching
permissions is granted."

Where in your example '*' acts like a group which contains all users.

One solution to this problem is to define a group which includes everyone
except 'myuser' and then use give access to the root path to this group.

By the way, you can use the 'svnauthz accessof' command to test your ruleset.
Torsten Krah
2018-01-22 12:12:40 UTC
Permalink
Good catch, but this does not explain the first example of the OP:

[repo:/]
myuser = rw
- The client (curl) shows me the repo-root but none of the files below.
- The error_log shows, that my user got authorized on root:
[Fri Jan 19 21:20:58.735108 2018] [authz_svn:info] [pid 3465:tid
140589093869312] [client ::1:59812] Access granted: 'myuser' GET (null)
- But I'm not allowed to see a file below:
[Fri Jan 19 21:20:58.735706 2018] [authz_svn:info] [pid 3465:tid
140589093869312] [client ::1:59812] Access denied: - GET
repo:/muhmiau.txt


This should be allowed but fails, ideas?

kind regards

Torsten
Torsten Krah
2018-01-23 13:45:21 UTC
Permalink
Post by Stefan Hauffe
[repo:/]
myuser = rw
- The client (curl) shows me the repo-root but none of the files below.
[Fri Jan 19 21:20:58.735108 2018] [authz_svn:info] [pid 3465:tid
140589093869312] [client ::1:59812] Access granted: 'myuser' GET (null)
[Fri Jan 19 21:20:58.735706 2018] [authz_svn:info] [pid 3465:tid
140589093869312] [client ::1:59812] Access denied: - GET
repo:/muhmiau.txt
This should be allowed but fails, ideas?
kind regards
Torsten
Just curious about that too - i did some further tests here with the
latest svn trunk + httpd 2.4.29 and this config based on the "cfg" file
from the basic_tests.py (just removed the basic auth part and put the
lua call in):

<Location /svn-test-work/repositories>
DAV svn
SVNParentPath
"/home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/repositories"
LuaHookCheckUserID /etc/apache2/auth.lua authcheck_hook early
AuthzSVNAccessFile
"/home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz"
Require valid-user
SVNAdvertiseV2Protocol on
SVNCacheRevProps off
</Location>

1. First test with this in authz file:

[/]
* = rw

Then error.log reads like that if i request "basic_tests-10/iota"
resource:

http://localhost:3691/svn-test-work/repositories/basic_tests-10/iota

[Tue Jan 23 14:24:43.181106 2018] [mpm_event:debug] [pid 25340:tid
140737265346304] event.c(2175): AH02471: start_threads: Using epoll
(wakeable)
[Tue Jan 23 14:24:53.068175 2018] [authz_svn:debug] [pid 25340:tid
140737127630592] subversion/mod_authz_svn/mod_authz_svn.c(448): [client
127.0.0.1:17290] Path to authz file
is /home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068400 2018] [authz_svn:info] [pid 25340:tid
140737127630592] [client 127.0.0.1:17290] Access granted: - GET
basic_tests-10:/iota, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068416 2018] [authz_core:debug] [pid 25340:tid
140737127630592] mod_authz_core.c(809): [client 127.0.0.1:17290]
AH01626: authorization result of Require valid-user : denied (no
authenticated user yet), referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068421 2018] [authz_core:debug] [pid 25340:tid
140737127630592] mod_authz_core.c(809): [client 127.0.0.1:17290]
AH01626: authorization result of <RequireAny>: denied (no authenticated
user yet), referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068748 2018] [lua:debug] [pid 25340:tid
140737127630592] lua_request.c(1838): [client 127.0.0.1:17290] AH01486:
request_rec->dispatching headers_in -> apr table, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068762 2018] [lua:debug] [pid 25340:tid
140737127630592] lua_request.c(1856): [client 127.0.0.1:17290] AH01488:
request_rec->dispatching user -> string, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068768 2018] [lua:debug] [pid 25340:tid
140737127630592] lua_request.c(1856): [client 127.0.0.1:17290] AH01488:
request_rec->dispatching user -> string, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068772 2018] [lua:debug] [pid 25340:tid
140737127630592] lua_request.c(1848): [client 127.0.0.1:17290] AH01487:
request_rec->dispatching debug -> lua_CFunction, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068778 2018] [lua:debug] [pid 25340:tid
140737127630592] @/etc/apache2/auth.lua(23): [client 127.0.0.1:17290]
user foo: OK, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068793 2018] [authz_svn:debug] [pid 25340:tid
140737127630592] subversion/mod_authz_svn/mod_authz_svn.c(448): [client
127.0.0.1:17290] Path to authz file
is /home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:24:53.068823 2018] [authz_svn:info] [pid 25340:tid
140737127630592] [client 127.0.0.1:17290] Access granted: 'foo' GET
basic_tests-10:/iota, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/


So the access is granted in the first line to "-", after that authz_core
determines that there is yet no user authenticated and the call flow
reaches the configured lua auch hook via authz_core (1:1 from the httpd
docs
https://httpd.apache.org/docs/2.4/de/mod/mod_lua.html#luahookaccesschecker) which sets the user and after that authz_svn:info is happy to grant access to user 'foo' for that resource in the last line - fine so far.

Now the second test with that in authz file:

[/]
foo = rw

This should work the same (shouldn't it) - the user will be 'foo' - but
this is the debug output:

[Tue Jan 23 14:31:56.714114 2018] [authz_svn:debug] [pid 27435:tid
140737127630592] subversion/mod_authz_svn/mod_authz_svn.c(448): [client
127.0.0.1:17374] Path to authz file
is /home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Tue Jan 23 14:31:56.714376 2018] [authz_svn:error] [pid 27435:tid
140737127630592] [client 127.0.0.1:17374] Access denied: - GET
basic_tests-10:/iota, referer:
http://localhost:3691/svn-test-work/repositories/basic_tests-10/

After that the request is already answered with 403 and finished.

mod_authz_core.c had not yet even a chance to run to the authentication
phase and delegate that to the configured lua script.

Any ideas why that request with the user "-" is denied here instead of
processing the chain like above - meaning granted without knowing the
user yet and later on verified and granted with the correct user?

Ideas? Any hints where to put some breakpoints and post values here - i
am not that familiar with the svn source to get the interesting method
calls and values via some gdb help ;).

kind regards

Torsten
Torsten Krah
2018-01-24 10:05:40 UTC
Permalink
Some more news about that, debugged that a little bit further and imho i
think its a bug in the module code of access_checker - or there are
assumptions made which do not hold in my usecase - at least its unclear
to me why its done that way, maybe someone can give some input.

The problem is that the authorization module mod_authz_svn does expect a
AuthType to be set and that a Authorization header must be there - but
this is optional - authentication can be done without both of them using
lua:

https://httpd.apache.org/docs/2.4/de/mod/mod_lua.html#luahookauthchecker

...
Invoke a lua function in the auth_checker phase of processing a request. This can be used to implement arbitrary authentication and authorization checking.
...

Looking in the RedBean book it reads:

http://svnbook.red-bean.com/de/1.8/svn.serverconfig.httpd.html#svn.serverconfig.httpd.ref.mod_authz_svn

...
Die folgenden Konfigurations-Direktiven werden geliefert von
mod_authz_svn, Subversions Apache HTTP Server Modul fÃŒr pfad-basierte
Autorisierung.
...

So its about Authorization, not Authentication in that module - why does
the Authorization part makes assumptions about how authentication is
done?

The code in question (to me) is this (trunk):

886 /* Authentication is configured */
887 authn_configured = ap_auth_type(r) != NULL;
888 if (authn_configured)
889 {
890 /* If the user is trying to authenticate, let him. It doesn't
891 * make much sense to grant anonymous access but deny authenticated
892 * users access, even though you can do that with '$anon' in the
893 * access file.
894 */
895 if (apr_table_get(r->headers_in,
896 (PROXYREQ_PROXY == r->proxyreq)
897 ? "Proxy-Authorization" : "Authorization"))
898 {
899 /* Set the note to force authn regardless of what access_checker_ex
900 hook requires */
901 apr_table_setn(r->notes, FORCE_AUTHN_NOTE, (const char*)1);
902
903 /* provide the proper return so the access_checker hook doesn't
904 * prevent the code from continuing on to the other auth hooks */
905 if (ap_satisfies(r) != SATISFY_ANY)
906 return OK;
907 else
908 return HTTP_FORBIDDEN;
909 }
910 }

I was able to get the authentication running using gdb and doing a:

set authn_configured=1

on line 888.

Line 887 assumes that Authentication is only configured if there is a
auth_type set on the request, but this is wrong - its not needed to
authenticate a user, see the lua docs.

After that it runs the code where the "Authorization" is checked - L885:

(gdb) print apr_table_get(r->headers_in, "Proxy-Authorization")
$8 = 0
(gdb) print apr_table_get(r->headers_in, "Authorization")
$9 = 0
(gdb)

This should not be done here (at least there should be a way to skip that) - i did not sent and did not ask the user to sent this header so, its not basic authentication here.
If i do sent an arbitrary faked Authorization header, which has nothing
todo with what authentication needs, it passes and the lua hook is
called and the request does succeed like this:

[Wed Jan 24 09:45:02.751169 2018] [authz_core:debug] [pid 12109:tid 140737127630592] mod_authz_core.c(809): [client 127.0.0.1:18984] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751214 2018] [authz_core:debug] [pid 12109:tid 140737127630592] mod_authz_core.c(809): [client 127.0.0.1:18984] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751644 2018] [lua:debug] [pid 12109:tid 140737127630592] lua_request.c(1838): [client 127.0.0.1:18984] AH01486: request_rec->dispatching headers_in -> apr table, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751663 2018] [lua:debug] [pid 12109:tid 140737127630592] lua_request.c(1856): [client 127.0.0.1:18984] AH01488: request_rec->dispatching user -> string, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751670 2018] [lua:debug] [pid 12109:tid 140737127630592] lua_request.c(1856): [client 127.0.0.1:18984] AH01488: request_rec->dispatching user -> string, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751676 2018] [lua:debug] [pid 12109:tid 140737127630592] lua_request.c(1848): [client 127.0.0.1:18984] AH01487: request_rec->dispatching debug -> lua_CFunction, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751682 2018] [lua:debug] [pid 12109:tid 140737127630592] @/etc/apache2/auth.lua(23): [client 127.0.0.1:18984] user foo: OK, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751706 2018] [authz_svn:debug] [pid 12109:tid 140737127630592] subversion/mod_authz_svn/mod_authz_svn.c(448): [client 127.0.0.1:18984] Path to authz file is /home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/
[Wed Jan 24 09:45:02.751902 2018] [authz_svn:info] [pid 12109:tid 140737127630592] [client 127.0.0.1:18984] Access granted: 'foo' GET basic_tests-10:/iota, referer: http://localhost:3691/svn-test-work/repositories/basic_tests-10/

Without that header it passes too - but the callstack is different (just
for information).

948 status = req_check_access(r, conf, &repos_path, &dest_repos_path);

After this it takes is way to L884 which returns DECLINED.

Run till exit from #0 ap_some_authn_required (r=0x7ffff7f310a0) at request.c:149
0x00007ffff2b55389 in access_checker (r=0x7ffff7f310a0) at subversion/mod_authz_svn/mod_authz_svn.c:968
968 authn_required = ap_some_authn_required(r);
Value returned is $5 = 1

After that the request asks the lua hook for the user and later on
mod_authz_svn can check the path based stuff which succeeds:

[Wed Jan 24 10:34:38.624611 2018] [authz_svn:debug] [pid 1841:tid 140737152808704] subversion/mod_authz_svn/mod_authz_svn.c(448): [client 127.0.0.1:19746] Path to authz file is /home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz
[Wed Jan 24 10:36:50.581672 2018] [authz_core:debug] [pid 1841:tid 140737152808704] mod_authz_core.c(809): [client 127.0.0.1:19746] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Wed Jan 24 10:36:50.581740 2018] [authz_core:debug] [pid 1841:tid 140737152808704] mod_authz_core.c(809): [client 127.0.0.1:19746] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Wed Jan 24 10:39:27.506910 2018] [authz_core:debug] [pid 1841:tid 140737152808704] mod_authz_core.c(809): [client 127.0.0.1:19746] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Wed Jan 24 10:39:27.506972 2018] [authz_core:debug] [pid 1841:tid 140737152808704] mod_authz_core.c(809): [client 127.0.0.1:19746] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Wed Jan 24 10:39:27.507366 2018] [lua:debug] [pid 1841:tid 140737152808704] lua_request.c(1848): [client 127.0.0.1:19746] AH01487: request_rec->dispatching debug -> lua_CFunction
[Wed Jan 24 10:39:27.507384 2018] [lua:debug] [pid 1841:tid 140737152808704] @/etc/apache2/auth.lua(13): [client 127.0.0.1:19746] user foo: OK
[Wed Jan 24 10:39:27.507412 2018] [authz_svn:debug] [pid 1841:tid 140737152808704] subversion/mod_authz_svn/mod_authz_svn.c(448): [client 127.0.0.1:19746] Path to authz file is /home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz
[Wed Jan 24 10:39:27.507487 2018] [authz_svn:info] [pid 1841:tid 140737152808704] [client 127.0.0.1:19746] Access granted: 'foo' GET basic_tests-10:/iota


HTH someone to dive into that - should i file a Bug about that in the tracker to get that fixed?

kind regards

Torsten
Stefan Sperling
2018-01-24 10:48:14 UTC
Permalink
Post by Torsten Krah
Some more news about that, debugged that a little bit further and imho i
think its a bug in the module code of access_checker - or there are
assumptions made which do not hold in my usecase - at least its unclear
to me why its done that way, maybe someone can give some input.
HTH someone to dive into that - should i file a Bug about that in the tracker to get that fixed?
Thanks for investigating this!

You've provided enough context for filing an issue, but just filing
an issue and waiting on it is not going to get the problem fixed.

You will have to find the attention of somebody who, ideally, is both
an SVN dev and very familiar with httpd auth framework internals.

I think your best next step is to re-open this discussion on the dev@
mailing list and share all the details of your investigation there.

On dev@ you could also include a proof of concept patch to show how you
would fix the problem based on your current understanding of things.
A patch doesn't have to be perfect on first try.
See http://subversion.apache.org/docs/community-guide/general.html#patches
Loading...