[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: Lieven Govaerts <lgo_at_mobsol.be>
Date: 2006-01-22 15:16:34 CET

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
Received on Sun Jan 22 15:19:36 2006

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

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