On Thu, 2009-10-01 at 10:53 -0400, Mark Phippard wrote:
> On Thu, Oct 1, 2009 at 10:48 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > I'm thinking about the data-hiding part of "obliterate".
> >
> > Example: obliterate (hide) /path/to/foo in revision 50.
> >
> >
> > * Approach 1:
> >
> > Edit the FS in the database: replace the old revision 50 with a new
> > transaction that's mostly the same except doesn't have an entry for
> > "foo" in its "/dir/to" directory node. "Commit" the new transaction in
> > place of revision 50, adjusting all links that pointed to the old
> > revision 50 to point to the new one instead.
> >
> > This is an FS-layer change, plus support needed in the DB layers to be
> > able to replace an existing revision and edit other metadata.
> >
> >
> > * Approach 2:
> >
> > Extend Subversion's path-based authz semantics to enable us to block
> > access to /path/to/foo_at_50.
>
> I do not think this would be a great way to do it. mod_authz_svn is
> an optional module and [...]
Thanks for the comments. This is just the sort of thing I need to
understand and think about.
I didn't explain what I meant. For the purposes of explaining this line
of thought, the way I imagine path-based authz works now is (please
excuse the crudeness of my understanding):
1. Subversion wants to know if it can read or write something;
2. mod_dav_svn (or other plug-in authz module) is asked (by
Subversion or by Apache, doesn't matter here) about path P
for user U;
3. mod_dav_svn (or other) consults its authz rules or database
and replies "writable" or "read-only" or "no access";
4. Subversion takes one of three different actions depending on
whether the "authz result" is "writable" or "read-only" or
"no access".
I am not thinking of extending mod_dav_svn, but rather of extending the
Subversion-internal side of this interaction. Extending the idea of
Subversion's question (step 1) to include "at revision R" and extending
if necessary the way Subversion handles its three different actions
(step 4). Then implementing the "obliterated node-revs" database and the
obliteration-authz look-up function centrally within Subversion. Like
this:
1. Subversion wants to know if it can read or write something;
2. mod_dav_svn (or other plug-in authz module) is asked (by
Subversion or by Apache, doesn't matter here) about path P
for user U;
3. mod_dav_svn (or other) consults its authz rules or database
and replies "writable" or "read-only" or "no access";
+ 4. Subversion asks its "obliterated path-revs database" whether
path P at rev R is accessible; if not, then change the authz
result to "no access";
5. Subversion takes one of three different actions depending on
whether the "authz result" is "writable" or "read-only" or
"no access".
The set up and administration of the "obliterated path-revs database"
used in step 4 can be completely new, not tied to mod_authz_svn or to
any optional component, and can have whatever administrative interface
we want.
The last step (step 5) is interesting to me, as that is where Subversion
knows how to deal with a path that it can no longer access (or rather is
no longer allowed to send to the client). This is a crucial piece of the
"obliterate" puzzle. The feasibility of this approach depends on the
degree to which Subversion is tied to path-based rather than path-rev
based authz in this operation.
> Besides, a very common use case today for obliterate is to simply
> block that a path ever existed in the repository (all revisions).
> This can be done today using authz but I have never heard anyone
> suggest they considered that a decent option. So there is no reason
> to think taking this idea further would help.
That doesn't sound quite right. I strongly expect that people are
already using path-based authz to hide paths that unexpectedly became
sensitive. Admittedly the method of its administration and the fact that
it's specific to HTTP and svnserve access methods make it not the ideal
interface for obliteration, so maybe people do find it "not a decent
option". But I'm not thinking of building on the existing
implementations of path-based authz so I think this is moot.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402573
Received on 2009-10-01 17:47:23 CEST