Mark Phippard wrote:
> On Thu, Mar 12, 2009 at 2:18 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
>> Mark Phippard wrote:
>>
>>> On Thu, Mar 12, 2009 at 1:39 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>>
>>>> Ben Collins-Sussman wrote:
>>>>
>>>>> This is the *best* explanation I've ever seen of the problem. Mucho
>>>>> applause! So much easier to understand. I agree with everything you
>>>>> said.
>>>>>
>>>>> I don't have any brilliant ideas about the 2 showstoppers right now,
>>>>> but it's great to have it all laid out like this.
>>>>>
>>>> I've filed issue #3380 for tracking the necessary overhaul, and will toss an
>>>> item into tasks.html for this.
>>>>
>>> Changing the security model seems relatively straight forward and I
>>> imagine the only real barrier to just doing it is that the current WC
>>> leaks too much information in the entries file. So what exactly is
>>> the RFC about? Ideas about how to make the WC less leaky? Whether
>>> the current leakage is OK? or something else?
>>>
>> Well, I'd certainly like to solve the leakage problem, but gstein has me
>> convinced that that's not really possible. The RFC was mostly aimed at
>> changing the security model. And lo and behold, you commented on that very
>> thing!
>>
>
> I am not really sure what I think about the leakage. I've never
> worked in an environment where we tried to hide the existence of
> stuff. Deny write access, sure, or deny any access at all to entire
> repos, sure. But never the "you can see this but not that" model. So
> it is hard to know what people that want that sort of environment care
> about.
>
> I can say, that I'd really, really like the ViewVC "browse" model to
> work in TortoiseSVN, Subclipse etc. So that you could browse from the
> root of the repos down to your area.
>
'S called "directory traversal" permission on Windows, and "directory
executable bit" on Unix. IMO trying to hide existence of stuff would
require some kind of ACL support on the FS level; and lots of support on
the server, e.g., for edge cases like renames between visible and hidden
areas (shudder). This is probably so rarely needed that the obvious
workaround (split the repository in two) is likely sufficient.
Regarding information leaking in the WC, though; leaking the mere
existence of paths is acceptable, but if you can't read something, you
shouldn't have, e.g., its properties or its pristine text in the working
copy. That part could become quite tricky.
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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1313932
Received on 2009-03-12 19:47:17 CET