[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC

From: Holger Stratmann <tigris_at_finch.de>
Date: 2006-01-23 13:11:22 CET

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?


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
>scheme, and is case sensitive. So [TSECRET:/] does not match 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
> because test 1 will still deny it.
>- if in the access file you're granted write access to [SECRET:/trunk], you
> change, add, delete (...) files from a working copy pointing to repo
>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
>>-----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"
>>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
>>* = 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
>>* = 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 :-)

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.