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

RE: How to prevent casual browsing

From: Geoff Field <Geoff_Field_at_aapl.com.au>
Date: Mon, 2 Dec 2013 08:50:12 +1100

Hi Peter

> From: Peter Flynn
> Sent: Monday, 2 December 2013 1:40 AM
>
> I have a number of svn repositories running under
> Apache+subversion on CentOS6/64, with Submin to provide a web
> GUI to manage them:
>
> server.name/svn/foo
> server.name/svn/bar
> server.name/svn/blort
> etc
>
> All of them are private; all but one of them are single-user
> (me) so that I can carry on working from any of my machines
> in multiple locations. One of them is shared with colleagues
> on a project: they all have read/write privs on that repo.

Are they separate projects or separate accesses to the same project? You know, of course, that you can set up authz privileges to specific subdirectories?

> The URIs are not published or linked, and my colleagues are
> all well aware of the need to keep their shared URI private.
> But the requirement is that none of them must be open to
> casual read access via a web browser, in case someone happen
> to stumble upon or guess the URI.
>
> I am having problems getting the access privs right, as they
> keep causing "svn: E220000: Not authorized to open root of
> edit operation"
> during an svn up. However, in a long exchange with the very
> helpful submin support
> (https://ssl.supermind.nl/collab/projects/submin/ticket/336)
> we have failed to identify settings that work.

Not sure about this one.

> Currently the svn/conf/authz file says
>
> > [groups]
> > dev = a,b,c,d,e,me
> >
> > [foo:/]
> > @dev = rw
> >
> > [bar:/]

For the private one, try adding the following line here:
* =
That turns off read and write access for everybody EXCEPT the explicitly-named members. At least, it works that way for us.

> > me = rw
> >
> > [blort:/]
> > me = rw
>
> The Apache conf.d/subversion.conf says:
>
> > <Location /svn>
> > DAV svn
> > SVNParentPath /var/lib/submin/svn
> > # removed GET from LimitExcept to prevent casual browsing
> > <LimitExcept PROPFIND OPTIONS REPORT>
> > AuthType Basic
> > AuthName "Authorization Realm"
> > AuthUserFile /etc/svn.auth
> > Require valid-user
> > </LimitExcept>
> > </Location>
>
> and svn.auth specifies a username:encryptedpassword pair for
> each member of [groups] in the usual way.
>
> 1. Browsing with a web browser causes a prompt for the
> username/password as expected.
>
> 2. An svn ci operation works fine.
>
> 3. An svn up operation fails, and always causes an E220000 error.
>
> 4. Replacing the GET in the LimitExcept config allows svn up
> to work without error, but allows casual browsing of the web
> interface.
>
> Is there a way to prevent the casual browsing while avoiding
> the E220000 error?

-- 
Apologies for the auto-generated legal boilerplate added by our IT department:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 
Received on 2013-12-01 22:50:53 CET

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.