Reving the Editor Interface for Move Support

[Garrett Rooney <ro...@electricjellyfish.net>]

As part of the work on atomic renames, I'm looking at reving the
editor interface.  We need the ability to express move operations, and
due to our backwards compatibility constraints it appears we can't do
that without reving the whole interface.

I'm thinking we might also want to consider making the structure
opaque, similar to what was done with the RA layer API, with the
addition of some accessor functions for manipulating the underlying
callbacks.

I've got a few questions though, before I go in and start messing
around with this...

First, does anyone object to making the new editor object opaque? 
It'll make code that creates editors a bit more verbose, but I don't
personally think that's a huge problem...

Perhaps more important, how should move operations actually be
expressed?  Basically, it appears that we're going to need both FROM
and TO callbacks (due to the fact that we might only see part of the
operation in any given editor drive), so a move will actually involve
a call for the source (I'm moving from HERE to THERE), and the
destination (I'm showing up HERE and I was renamed from THERE).  The
destination part is similar to what we already do with adds + history,
but there needs to be some way to indicate that this was a rename, so
either the add callbacks need to grow "is a rename" parameters, or new
callbacks are needed.  On the other end it's very similar to what we
currently have for delete entry, but with the addition of the
destination info.  That could be implemented by reving the
delete_entry function, adding some parameters, or via a separate
callback that is only used for renames.

The current half-done impl I've got on the fs-atomic-renames branch
uses new callbacks for the move stuff, but I'm personally leaning
towards at least reving delete, and potentially doing the same for
add, since it won't even result in ugly svn_foo_bar2 type function
names since if we go with an opaque editor we'll need new helper
functions to do the actual calling, which can have new names
obviously, and keeping the total number of functions down seems
useful, since we have so damn many of them now...

Any thoughts?

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Reving the Editor Interface for Move Support

[Garrett Rooney <ro...@electricjellyfish.net>]

On 4/4/06, Michael Brouwer <mb...@gmail.com> wrote:
> Not commenting on the specifics of your idea here per-se, but on a
> potential security issue regarding renames.
>
> If the ACLs on a repository disallows someone access to the move
> source of a file, what would the move source be in the editor call?
>
> More detailed example: Say a repository was split in a secret and a
> public part (using ACLs), and someone with access to both moves a file
> from the secret to the public part because that file was deemed to not
> be private anymore, can this be done without disclosing any
> information about the private sections of the repository (such as path
> names) to people without access to those private sections.
>
> It seems like the right thing to do here might be to show the file as
> having been added without history to users without access to the move
> source.

That's what we do for copies now, I imagine we'll do something similar
for renames.

> The opposite scenario is also possible I assume (someone moves a
> public file to the private section of the repository).  After this to
> users without access to the private section the move should arguably
> show up as a delete to users without access to the move destination.

That's what I'd been thinking as well.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Reving the Editor Interface for Move Support

[Michael Brouwer <mb...@gmail.com>]

Not commenting on the specifics of your idea here per-se, but on a
potential security issue regarding renames.

If the ACLs on a repository disallows someone access to the move
source of a file, what would the move source be in the editor call?

More detailed example: Say a repository was split in a secret and a
public part (using ACLs), and someone with access to both moves a file
from the secret to the public part because that file was deemed to not
be private anymore, can this be done without disclosing any
information about the private sections of the repository (such as path
names) to people without access to those private sections.

It seems like the right thing to do here might be to show the file as
having been added without history to users without access to the move
source.

The opposite scenario is also possible I assume (someone moves a
public file to the private section of the repository).  After this to
users without access to the private section the move should arguably
show up as a delete to users without access to the move destination.

Michael


On 4/3/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> Perhaps more important, how should move operations actually be
> expressed?  Basically, it appears that we're going to need both FROM
> and TO callbacks (due to the fact that we might only see part of the
> operation in any given editor drive), so a move will actually involve
> a call for the source (I'm moving from HERE to THERE), and the
> destination (I'm showing up HERE and I was renamed from THERE).  The
> destination part is similar to what we already do with adds + history,
> but there needs to be some way to indicate that this was a rename, so
> either the add callbacks need to grow "is a rename" parameters, or new
> callbacks are needed.  On the other end it's very similar to what we
> currently have for delete entry, but with the addition of the
> destination info.  That could be implemented by reving the
> delete_entry function, adding some parameters, or via a separate
> callback that is only used for renames.