[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: unsafe authorisation hack?

From: Aidan Kane <temp_at_scue.co.uk>
Date: 2007-04-03 00:12:19 CEST

thanks for the comments, all fair points.

my first approach was to use AuthzSVNAccessFile, however this has a
couple of problems.

the first issue I ran into was that I couldn't find a way to integrate
it with Groups in the windows domain (maybe there's a way of doing
this but I don't see how it could possibly work). not a major issue
though as I was happy enough to work around it by just specifying the
groups in the Auth File.

the more significant issue was the performance hit when using the 'svn
log' command. Our repository is structured in such a way that a single
branch contains about 2gb of code, so getting a log on any branch
tends to be a rather heavy process.

the second attempt was to apply apache 'require group' rules to the
incoming svn urls. problem here is that much of the grunt work is
actually done on the internal svn structure (thus the need for an
AuthzSVNAccessFile in the first place). we got a lot of the desired
behaviour but couldn't get all the way there (we couldn't control
people copying directly via the repo-browser in tsvn for example).

so we hacked the !svn urls! I know that we risk having things break on
us in the future, but that may turn out to be a risk worth taking.

personally I'd rather not apply any authorization constraints at all
but as always it has to be done for reasons beyond my control.

I'm not aware of any other svn authorization methods that work in
apache, but would clearly be grateful to anyone able to point to more


On 4/2/07, Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
> On Apr 2, 2007, at 08:03, temp temp wrote:
> > I'm currently trying to add a little bit of authorisation to one of my
> > repositories that is served by apache. I found that using the normal
> > svn authorisation mechanism made retrieving log messages too slow to
> > be usable.
> >
> > I then tried a basic system of limiting access to certain Locations
> > (and dav commands):
> >
> > <Location /svn/web/live/>
> > RequireGroup blah
> > </Location>
> >
> > This worked pretty well. Unfortunately it still allows users to drag
> > folders around within the repo-browser (I'm trying to avoid people
> > accidentally moving important folders).
> >
> > I'm now using the LocationMatch tag directly on the !svn locations
> > (LocationMatch is required to regex match the unknown version number):
> >
> > <LocationMatch "/2ndbyte/!svn/ver/[^/]*/web/live.*">
> > RequireGroup blah
> > </LocationMatch>
> >
> > My question is basically - is this safe? I'm no apache/svn expert so I
> > don't really understand the risks. Obviously it's much harder to get
> > the rules correct this way (as it's pretty cumbersome). Mostly I'm
> > worried that this might allow part of a commit to complete but then
> > fail too late in the process to roll back.
> [snip]
> I've never seen the format of these !svn URLs described, so I believe
> they are considered internal to Subversion and subject to change in
> future versions without notice. My feeling is it's probably not a
> good idea to try to use them in an authorization scheme (or in any
> other way).
> I have not needed to use authorization in my repositories so I'll let
> someone else suggest a better solution. But surely authorization is a
> problem that has been well solved in Subversion so I'm sure there are
> some reasonable suggestions that will help you. You did not mention
> which Subversion authorization mechanisms you had tried so far... You
> said "all" but maybe there are some which you are not aware of which
> you haven't tried...
> --
> To reply to the mailing list, please use your mailer's Reply To All
> function

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 3 00:12:38 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.