You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Holger Stratmann <ti...@finch.de> on 2006/01/18 12:53:07 UTC
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Michal Levý wrote:
> Relocating wc to uppercase repo name works great! thanks for
> suggestions....
>
> Still. This behavior were introduced by 1.3.0 and it seems to me like
> a inconsistency.
> SVN client works without complaints with different cased repo names
> (maybe only on Windows), why authorization mechanism don't ?
This is not uncommon (only on Windows!). The authorization is operating
"in memory" and comparing strings. That's always case sensitive by
default (unless specifically made case insensitive).
Accessing the repository goes to the file system and requests a
directory called "TVM" - Windows happily returns "tvm" or "Tvm" or whatever.
I am wondering if THAT is acceptable behavior for Subversion?
AFAIK, this should work (not that I'm doing it):
[/]
* = r
[secret:/]
* =
me = rw
Am I wrong?
On Windows, that's now heavily broken, because I could still access
"Secret" or "seCret" or something like that as an anonymous user, right?
I think this should be changed in one of two ways:
a) make authentication case insensitive on Windows (seems like it was in
1.2.3? However, on other operating systems it has to be case sensitive,
so maybe it was "fixed for *nix" in 1.3.0? :-) Or it's actually a
(regression) bug)
b) make repository access case sensitive even on Windows (a case
preserving version of the filename is available from the Win API if you
want it)
Holger
>
> Anyway, i consider to rename all repo names to lowercase (but it will
> be painful)
>
> thanks for your time
>
> Michal Levy
>
> Lieven Govaerts wrote:
>
>> Michal,
>>
>>
>> Quoting Michal Levý <mi...@mediaresearch.cz>:
>>
>>> Thanks for reply
>>>
>>> Case sensitive ? But repo directory (located at C:\Data\SVN) is
>>> named TVM...
>>> Yes, I'm sure. Everything worked fine until upgrade to 1.3.0
>>>
>>
>> this error message you reported:
>>
>>> Error: MKACTIVITY of
>>> '/svn/tvm/!svn/act/7dff391b-9d6b-0d4c-a0a5-6cf978297dda':
>>> 403 Forbidden (http://stoupa:8080)" > Message in Apache error log
>>> is: "[Tue
>>
>> Jan 17 11:02:15 2006] [error]
>>
>>> [client 192.168.0.1] Access denied: 'peta' MKACTIVITY tvm: "
>>
>>
>> suggests that the working copy points to http://stoupa:8080/svn/tvm (
>> with
>> lowercase tvm ).
>>
>> Can you try to relocate ( switch --relocate ) those working copies to
>> http://stoupa:8080/svn/TVM to see if that makes a difference for you?
>>
>> Lieven.
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Lieven Govaerts <lg...@mobsol.be>.
Holger,
Quoting Holger Stratmann <ti...@finch.de>:
> Hi Lieven and everybody :-),
>
> Lieven Govaerts wrote:
>
...
> 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?
I filed this issue yesterday evening under nr. 2485, after a discussion with one
of the svn developers. The description of that issue contains a more detailed
analysis of the root cause.
> 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 ;-)
As a matter of fact yes they are also case insensitive on Unix, so the situation
you describe is indeed part of the issue! ( good thinking! ).
regards,
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/23/06, Holger Stratmann <ti...@finch.de> wrote:
> Anyway: I think this can now be considered an issue, right?
>
> Should I file it in the issue tracker?
Lieven already filed it as issue 2485.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Lieven Govaerts <lg...@mobsol.be>.
Holger,
Quoting Holger Stratmann <ti...@finch.de>:
> Hi Lieven and everybody :-),
>
> Lieven Govaerts wrote:
>
...
> 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?
I filed this issue yesterday evening under nr. 2485, after a discussion with one
of the svn developers. The description of that issue contains a more detailed
analysis of the root cause.
> 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 ;-)
As a matter of fact yes they are also case insensitive on Unix, so the situation
you describe is indeed part of the issue! ( good thinking! ).
regards,
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 1/23/06, Holger Stratmann <ti...@finch.de> wrote:
> Anyway: I think this can now be considered an issue, right?
>
> Should I file it in the issue tracker?
Lieven already filed it as issue 2485.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Holger Stratmann <ti...@finch.de>.
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
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Holger Stratmann <ti...@finch.de>.
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Lieven Govaerts <lg...@mobsol.be>.
After a few hours of debugging mod_authz_svn, 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
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date: 20/01/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Holger Stratmann <ti...@finch.de>.
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
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.
>
>But, I found that the implementation is pretty weird and inconsistent:
>- when disabling access rights, it seems that the repository check is done
>case
> insensitve
>- when adding access rights, the check is done case sensitive.
>
>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.
>
>Lieven.
>
>
>>-----Original Message-----
>>From: Kalin KOZHUHAROV [mailto:kalin@thinrope.net]
>>Sent: donderdag 19 januari 2006 17:08
>>To: Holger Stratmann
>>Cc: users@subversion.tigris.org
>>Subject: Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
>>
>>Holger Stratmann wrote:
>>
>>>Michal Levý wrote:
>>>
>>>
>>>>Relocating wc to uppercase repo name works great! thanks for
>>>>suggestions....
>>>>
>>>>Still. This behavior were introduced by 1.3.0 and it seems
>>>>
>>to me like
>>
>>>>a inconsistency.
>>>>SVN client works without complaints with different cased
>>>>
>>repo names
>>
>>>>(maybe only on Windows), why authorization mechanism don't ?
>>>>
>>>This is not uncommon (only on Windows!). The authorization is
>>>operating "in memory" and comparing strings. That's always case
>>>sensitive by default (unless specifically made case insensitive).
>>>Accessing the repository goes to the file system and requests a
>>>directory called "TVM" - Windows happily returns "tvm" or "Tvm" or
>>>whatever.
>>>
>>>I am wondering if THAT is acceptable behavior for Subversion?
>>>
>>If below is working, then it certainly is not!
>>
>>
>>>AFAIK, this should work (not that I'm doing it):
>>>
>>>[/]
>>>* = r
>>>
>>>[secret:/]
>>>* =
>>>me = rw
>>>
>>>Am I wrong?
>>>
>>>On Windows, that's now heavily broken, because I could still access
>>>"Secret" or "seCret" or something like that as an anonymous
>>>
>>user, right?
>>Not sure that will work, and I am more than half asleep
>>now... Will test tomorrow. If that works... we'll have a HUGE
>>hole in security... I hope it does not.
>>
>>
>>>I think this should be changed in one of two ways:
>>>a) make authentication case insensitive on Windows (seems
>>>
>>like it was
>>
>>>in 1.2.3? However, on other operating systems it has to be case
>>>sensitive, so maybe it was "fixed for *nix" in 1.3.0? :-) Or it's
>>>actually a
>>>(regression) bug)
>>>
>>not a good idea
>>
>>
>>>b) make repository access case sensitive even on Windows (a case
>>>preserving version of the filename is available from the Win API if
>>>you want it)
>>>
>>times better
>>
>>Kalin.
>>
>>--
>>|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
>>+-> http://ThinRope.net/ <-+
>>|[ ______________________ ]|
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>--
>>No virus found in this incoming message.
>>Checked by AVG Free Edition.
>>Version: 7.1.375 / Virus Database: 267.14.20/234 - Release
>>Date: 18/01/2006
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Lieven Govaerts <lg...@mobsol.be>.
Good point, and worth checking very thoroughly.
I've done some basic tests and they show that your scenario doesn't work.
But, I found that the implementation is pretty weird and inconsistent:
- when disabling access rights, it seems that the repository check is done
case
insensitve
- when adding access rights, the check is done case sensitive.
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.
Lieven.
> -----Original Message-----
> From: Kalin KOZHUHAROV [mailto:kalin@thinrope.net]
> Sent: donderdag 19 januari 2006 17:08
> To: Holger Stratmann
> Cc: users@subversion.tigris.org
> Subject: Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
>
> Holger Stratmann wrote:
> > Michal Levý wrote:
> >
> >> Relocating wc to uppercase repo name works great! thanks for
> >> suggestions....
> >>
> >> Still. This behavior were introduced by 1.3.0 and it seems
> to me like
> >> a inconsistency.
> >> SVN client works without complaints with different cased
> repo names
> >> (maybe only on Windows), why authorization mechanism don't ?
> >
> > This is not uncommon (only on Windows!). The authorization is
> > operating "in memory" and comparing strings. That's always case
> > sensitive by default (unless specifically made case insensitive).
> > Accessing the repository goes to the file system and requests a
> > directory called "TVM" - Windows happily returns "tvm" or "Tvm" or
> > whatever.
> >
> > I am wondering if THAT is acceptable behavior for Subversion?
> If below is working, then it certainly is not!
>
> > AFAIK, this should work (not that I'm doing it):
> >
> > [/]
> > * = r
> >
> > [secret:/]
> > * =
> > me = rw
> >
> > Am I wrong?
> >
> > On Windows, that's now heavily broken, because I could still access
> > "Secret" or "seCret" or something like that as an anonymous
> user, right?
> Not sure that will work, and I am more than half asleep
> now... Will test tomorrow. If that works... we'll have a HUGE
> hole in security... I hope it does not.
>
> > I think this should be changed in one of two ways:
> > a) make authentication case insensitive on Windows (seems
> like it was
> > in 1.2.3? However, on other operating systems it has to be case
> > sensitive, so maybe it was "fixed for *nix" in 1.3.0? :-) Or it's
> > actually a
> > (regression) bug)
> not a good idea
>
> > b) make repository access case sensitive even on Windows (a case
> > preserving version of the filename is available from the Win API if
> > you want it)
> times better
>
> Kalin.
>
> --
> |[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
> +-> http://ThinRope.net/ <-+
> |[ ______________________ ]|
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 267.14.20/234 - Release
> Date: 18/01/2006
>
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date: 18/01/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: broken AuthzSVNAccessFile in 1.3.0 ? RFC
Posted by Kalin KOZHUHAROV <ka...@thinrope.net>.
Holger Stratmann wrote:
> Michal Levý wrote:
>
>> Relocating wc to uppercase repo name works great! thanks for
>> suggestions....
>>
>> Still. This behavior were introduced by 1.3.0 and it seems to me like
>> a inconsistency.
>> SVN client works without complaints with different cased repo names
>> (maybe only on Windows), why authorization mechanism don't ?
>
> This is not uncommon (only on Windows!). The authorization is operating
> "in memory" and comparing strings. That's always case sensitive by
> default (unless specifically made case insensitive).
> Accessing the repository goes to the file system and requests a
> directory called "TVM" - Windows happily returns "tvm" or "Tvm" or
> whatever.
>
> I am wondering if THAT is acceptable behavior for Subversion?
If below is working, then it certainly is not!
> AFAIK, this should work (not that I'm doing it):
>
> [/]
> * = r
>
> [secret:/]
> * =
> me = rw
>
> Am I wrong?
>
> On Windows, that's now heavily broken, because I could still access
> "Secret" or "seCret" or something like that as an anonymous user, right?
Not sure that will work, and I am more than half asleep now... Will test
tomorrow. If that works... we'll have a HUGE hole in security... I hope it
does not.
> I think this should be changed in one of two ways:
> a) make authentication case insensitive on Windows (seems like it was in
> 1.2.3? However, on other operating systems it has to be case sensitive,
> so maybe it was "fixed for *nix" in 1.3.0? :-) Or it's actually a
> (regression) bug)
not a good idea
> b) make repository access case sensitive even on Windows (a case
> preserving version of the filename is available from the Win API if you
> want it)
times better
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org