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?
> > Remote "load" seems scary -- How can I prevent my users from being
> able to use this command? Is the original
> > author of the dumped
> revision preserved, or is the author set to the user doing the load?
> Can users do
> > anything else bad, like changing repo UUID?
>
> Again, I expect that access control/ security is automatically taken
> care of in the RA layer. `svnrdump load` is just like a user making
> some changes and committing them one by one except the author and
> timestamp in the dumpfile are preserved. Why would you want to block
> this?
Please verify this with testing, instead of just assuming that it works
(not entirely sure if you are simply assuming, but it sounds a bit like it).
Do we already have unit tests for svnrdump which check for authz interactions?
(A quick look into svnrdump_tests.py suggests that we don't.)
This is important for the future as well.
There have been authz regressions before, due to lack of testing in this area.
Even if your tests now show that it works, we need regression tests in our
test suite to make sure that it will continue to work as expected.
So no changes people make in the future will break it.
Thanks,
Stefan
Received on 2010-08-19 22:31:06 CEST