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

Re: RFC: Subversion security model in need of update

From: Jeremy Whitlock <jcscoobyrs_at_gmail.com>
Date: Tue, 10 Mar 2009 15:39:21 -0600

> But there were two showstoppers with our naive implementation:
>  1.  First, Subversion has no way to look at the response to a "can I
>      read this?" query of the auth subsystem and know if the answer means
>      "Yes, you can read it and know everything about it", or just "You
>      can know it exists because (duh) you can read its children."
>      This means that we couldn't blot out metadata from directories
>      deemed readable solely because of the accessibility of their children.

This one is pretty simple actually. The way I did this for the proof
of concept you speak of is instead of asking a "black and white"
question of "Do you have the requested access at this path" I asked a
question that yielded three answers:

1) Do you have the requested access at the path
2) Do you have the requested access for the path and all of its children
3) Do you have the requested access for the path and/or any of its children

With those three things, you can easily distinguish between being
given access to the resource in question and its structure/metadata
(explicit access) and whether the access was granted in a way that was
done to allow traversal to the actual resource (implicit access).
This worked awesome but like you said, it leaked too much. Any
directory that you were given implicit access to, ended up with
metadata being leaked and a slew of paths you shouldn't know exist in
the entries file. Now...if Subversion were the one using this
security model, I'm sure there could be some sort of answer to the
problem but when you are a consumer of Subversion, there is no way to
work around this.

>  2.  Our current security concession -- the absent-entries leak --
>      gets arguably out of hand.  Today, Subversion leaks the name of
>      any unreadable immediate children of a readable directory.  But
>      if "readable" means "you can read at least some deep child of it",
>      then you find yourself leaking siblings all along the chain of
>      otherwise unreadable parent directories.

Agreed. This is exactly what we saw.

Take care,
Jeremy Whitlock
Received on 2009-03-11 00:01:50 CET

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