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:tigris@finch.de]
>>Sent: vrijdag 20 januari 2006 23:29
>>To: users@subversion.tigris.org
>>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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 23 13:14:36 2006