Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC

Hi Lieven and everybody :-),

Lieven Govaerts wrote:

>After a few hours of debugging mod_authz_svn
>...
>My opinion: the global access check should be case insensitive as well
>  
>
Thanks for doing all this research :-)
Considering I did not have the sources, I got pretty close to it, didn't 
I? :-)

Anyway: I think this can now be considered an issue, right?

Should I file it in the issue tracker?
Or do you want to do it because you know more about it now?

Holger

P.S.: Are these checks case insensitive on a Linux/Unix Server? At least 
in theory, "a" and "A" could be different repositores, right? Well, I 
guess that's "discouraged" anyway ;-)

>I come to this conclusion:
>
>1. the authorization mechanism itself is case insensitive. 
>In your example, that means "[TSECRET:/]" matches both TSecret, TSECRET &
>tsecret repositories. The test for write access is done in the CHECKOUT
>step. FYI, CHECKOUT is not the svn checkout, but the DeltaV checkout
>( http://www.webdav.org/deltav/protocol/rfc3253.html#rfc.section.4.3 )
>So if you see CHECKOUT: 403 Forbidden, that means you don't have access to 
>that folder as defined in the access file.
>
>2. In subversion 1.3, a new global access check was added as an extra 
>restriction. The global access check was introduced to fix issue #2388 .
>This global access check is an extra check on top of the normal
>authorization
>scheme, and is case sensitive. So [TSECRET:/] does not match TSecret,
>TSECRET
>or tsecret repositories.
>As far as I can tell, this global access check is only used for testing 
>on write access in any part of the repository in the MKACTIVITY step. 
>
>Both parts of the conclusion explain why we see what we see:
>
>- you cannot get read or write access by altering the case of the
>wc-repository, 
>  because test 1 will still deny it. 
>- if in the access file you're granted write access to [SECRET:/trunk], you
>can't
>  change, add, delete (...) files from a working copy pointing to repo
>SeCrEt.
>
>My opinion: the global access check should be case insensitive as well. All 
>authorization is handled by the normal algorithm anyhow, so there's no
>security
>risk. 
>
>Lieven.
>
>
>>-----Original Message-----
>>From: Holger Stratmann [mailto:[email protected]] 
>>Sent: vrijdag 20 januari 2006 23:29
>>To: [email protected]
>>Cc: Lieven Govaerts; 'Kalin KOZHUHAROV'
>>Subject: Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
>>
>>Hi everybody,
>>Lieven Govaerts wrote:
>>
>>
>>>Good point, and worth checking very thoroughly. 
>>>
>>>I've done some basic tests and they show that your scenario 
>>>
>>doesn't work. 
>>
>>there's definitely something strange going on...
>>I've done some "tests", but now I'm confused about 1.3.0 and 
>>also need some sleep :-) (or the sourcecode so see what's going on)
>>
>>I did some "experiments" with 1.2.3 and everything worked as 
>>I would have expected it - auth checks were completely case 
>>insensitive as far as I could tell (concerning the repo name) 
>>in basic "trial and error" 
>>testing.
>>
>>Then I switched to 1.3.0 and I can't quite figure out what's 
>>going on, BUT I have not found a security problem so far. 
>>However, it seems like the commit "permission granted" is 
>>case sensitive, while "permission denied" is case insensitive 
>>- or something like that, it's not worth trying to find out 
>>without source code... Well, better than the other way around *hehe*
>>
>>Anyway, I tried sth similar to the original poster:
>>[/]
>>* = r
>>hs=r
>>
>>[TSECRET:/]
>>* = r
>>hs = rw
>>
>>The working copy is checked out as "tsecret", I am hs.
>>I can NOT commit (in 1.3, I can in 1.2.3), because the case 
>>insensitive check FAILS.
>>So this confirms the OP's problem.
>>
>>Now the idea behind MY posting was this: If it fails to grant 
>>permission (because of wrong case), it might also fail to 
>>DENY permission (because of wrong case), right? (or so you'd 
>>think in modular programming)
>>
>>But when I try it the other way around:
>>[/]
>>* = r
>>hs=rw
>>
>>[TSECRET:/]
>>* = r
>>hs = r
>>
>>I cannot commit either.
>>The error message is different though!
>>(btw: If I "svn co TSECRET", this also works and I can even commit).
>>
>>The different error message suggests that the permission 
>>check is indeed wrong for the commit (!) - however, there's 
>>also some CHECKOUT involved which fails.
>>
>>I'm still not convinced there's no problem hiding somewhere ;-)
>>
>>
>>>I failed to do a custom build of Subversion on Windows to 
>>>
>>step through 
>>
>>>the code, I'll try to do that this weekend.
>>>
>>>This requires some more tests to verify what is really going on.
>>>
>>>
>>Yes, that would be good! :-) I've never built Subversion 
>>myself and currently don't have time to start doing that... 
>>(also, I'm "a Java guy")
>>
>>Keep us up to date :-)
>>(and tell me why my above tests behave strangely :-)
>>
>>Holger
>>
>