> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: donderdag 19 augustus 2010 13:30
> To: Ramkumar Ramachandra
> Cc: users_at_subversion.apache.org
> Subject: Re: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk
>
> On Thu, Aug 19, 2010 at 08:02:02PM +0000, Ramkumar Ramachandra wrote:
> > Feldhacker, Chris <Feldhacker.Chris <at> principal.com> writes:
> > > Remote "dump" makes sense -- and I assume everything being dumped
> is
> > subject to the authorization/access
> > > control restrictions that have
> > been put into place on the server, yes? (A particular path or file
> > won't be
> > > included in the dump if the user doesn't have permission to
> > access it, right?)
> >
> > Exactly. Since svnrdump works purely on the RA layer, authz should be
> > taken care of for free.
>
> Have you tested this?
No.. but this has been tested for svnsync, when the replay functionality was
added.
And besides how would the client be able to obtain the security settings
from the server, to apply them on the client?... To make sure that no client
can get access to files that it isn't supposed to?
I don't think it makes sense to even think about this. If there would be a
problem, it would be in the server side implementation of the replay api,
which is available since at least 1.5. And that would be a huge security
problem for all existing servers even without svnrdump.
So, while you might want to see an additional security review for the
existing replay api (Why not the other apis then?), I don't think it makes
sense to hold svnrdump on it. It only uses existing apis for obtaining the
data, nothing new.
And even if we would find an issue anybody can compile the current version
(which just uses public apis), so the entire server security would already
be broken.
Bert
Received on 2010-08-20 06:17:31 CEST