Problem with authorized user and SVN access

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with authorized user and SVN access

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.

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:[hidden email]]
Gesendet: Freitag, 5. Januar 2018 16:30
An: [hidden email]
Betreff: Re: Apache SVN module and LUA authentification hook

On 05.01.2018 16:00, Stefan Hauffe wrote:

>
> 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
> also a “Access denied” message on a SVN file path:
>
>  
>
> [lua:debug] [pid 6872:tid ] @/path/to/hook.lua(29): [client ip]
> 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
>
>  
>
> My simplest working LUA-Scripts goes here:
>
>  
>
> 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 authentication.)

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Problem with authorized user and SVN access

Stefan Sperling
On Mon, Jan 22, 2018 at 11:39:26AM +0000, Stefan Hauffe wrote:

> 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.

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.
Reply | Threaded
Open this post in threaded view
|

Re: Problem with authorized user and SVN access

Torsten Krah-2
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


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with authorized user and SVN access

Torsten Krah-2
Am Montag, den 22.01.2018, 13:12 +0100 schrieb Torsten Krah:

> 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
>
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

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with authorized user and SVN access

Torsten Krah-2
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


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problem with authorized user and SVN access

Stefan Sperling
On Wed, Jan 24, 2018 at 11:05:40AM +0100, Torsten Krah wrote:
> 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