Branko Čibej wrote:
> I've been thinking about Mike's example where you commit to two sibling
> directories whose parent you're not allowed to read. It's
> "straight-forward" to allow the editor to open the node but disallow any
> operations except child lookup on it; but that means the access check
> can no longer be done at node-open time -- or rather, it can if you
> assume the filesystem like model where you specify desired access in the
> open call, but it has to be enforced later on, too. Doing this on the
> server level (mod_dav_svn or svnserve) is, IMO, likely to cause more
> problems than it's worth. So that implies moving the access control to
> the FS layer. Something I've been advocating all along. :)
>
> -- Brane
Most of the time, I don't think we really need a directory traversal bit,
per se. We need only to understand that if somebody has read access to
/foo/bar/baz, Subversion needn't pretend that /foo and /foo/bar don't exist.
That doesn't require a single new authz access level -- "r" and "rw" still
do what you want. It just requires a new application of those existing rules.
The one catch is that if we continue to leak siblings as we do today, there
is some additional security in the model today that we will lose if we go
forward as I'd like to. A dictionary attack can reveal only the top-most
unreadable item. So if I don't have access to /private, I might be able to
learn that /private exists with a dictionary attack and a bunch of mkdirs(),
but I can't learn that, say, /private/competitor exists. Today if I have
access to /foo/bar/baz, I can't even perform such an attack on /foo/* (for
lack of access to /foo). In my recommended world, I would learn about
/foo/* and /foo/bar/* now, too.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1314046
Received on 2009-03-12 20:13:26 CET