> 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.
Received on 2009-03-11 00:01:50 CET