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
Received on Fri Jan 20 23:30:54 2006