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

Expansion of authz policy name leak (was: svn commit: r933194 - /subversion/trunk/subversion/mod_authz_svn/mod_authz_svn.c)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 12 Apr 2010 11:01:51 -0400

Kamesh Jayachandran wrote:
>> I would expect that a request to the parent directory would yield a
>> listing
>> that included the 'calc' and 'watch' repositories, but not the 'lamp'
>> one.
>>
>> Is that the case?
>>
>>
> No.
>
> These authz rule should *not* list anything inside the repo 'lamp' but
> not lamp itself when requested for the parent path root.
>
> The feature that you ask for is possible only if 'mod_dav_svn'(which
> implements SVNListParentPath) consults mod_authz_svn(or some authorizer)
> for every item listed which is not the case today.

That's right -- we would need to consult the authz file (or files -- there
could be many) in order to make the show/no-show determination for each
repository. But this is authorization/security we're talking about here, so
we need to move forward with caution.

IIUC, prior to your change, nobody who had enabled authz at all could make
use of the SVNListParentPath feature (because the authorization for that
display would systematically fail). But this also means that Subversion
never leaked the name of a repository that was intended to be private/hidden
from particular users. Now, we no longer suffer the blanket authz failure,
but we are showing the name of every repository in the parent directory
without regard to any authz rules whatsoever.

I'll grant that sorta-kinda there is some precedent here in that Subversion
has always compromised (albeit not so explicitly) the names of subtree roots
that are deemed unreadable by authz policy (see "KNOWN LEAKAGE OF UNREADABLE
PATHS" in the authz_policy.txt file). But our currently WebDAV directory
listing (GET handler) doesn't leak names in such a way, and I'm not sure we
should so readily introduce a leak of this sort).

How do other feel about this?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-04-12 17:02:25 CEST

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