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 <rooneg@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.
Received on Tue Apr 4 18:04:13 2006