I'm trying to provide a remote access to SVN server through Apache. The situation can be illustrated like this:


There is only one repository, which contains both projects.

The public projects can be viewed by anyone (only viewed, never modified). The restricted ones can be read/modified only by the users who belong to specific groups. The configuration is the following:

<Location "/root">
  DAV svn
  SVNPath [...]
  SVNIndexXSLT [...]
    require ldap-group CN=SVN Administrators,OU=Subversion,DC=example,DC=com

<Location "/root/public-project">
    require ldap-group CN=Project1 Contributors,OU=Subversion,DC=example,DC=com

<Location "/root/restricted-project">
  require ldap-group CN=Project2 Contributors,OU=Subversion,DC=example,DC=com
  1. Is it secure enough, or there is a possibility for a guest to access sensitive information from the restricted project?

  2. When updating the source of the public project through SVN, I get the following error:

    Not authorized to open root of edit operation

    Apache error.log shows the following elements:

    A failure occurred while driving the update report editor [500, #220000]
    Not authorized to open root of edit operation [500, #220000]

    As for access.log, it shows that the SVN client made a bunch of PROPFIND (response: HTTP 207) and OPTIONS (response: HTTP 200), and finally:

    "REPORT /root/!svn/vcc/default HTTP/1.1" 500 241

    What should I do to resolve this problem, i.e. enable public read-only access for the public project, while keeping the restricted one hidden from unauthorized users?

Note: granting GET privilege on /root makes it possible for a guest to load the source of the public project, but also makes the public behavior the default one. I would prefer restrict the access, and grant it only on nodes which contain public projects.

  • I assume that using an AuthzSVNAccessFile is out of the question since you need to use LDAP groups? Because that would be easier. Anyway, I suspect the <LimitExcept> in <Location /root> is the problem -- does it work with just that configuration disabled? – Shane Madden Sep 12 '13 at 6:18
  • @ShaneMadden: indeed, AuthzSVNAccessFile is out of the question. If I remove <LimitExcept> of the root, I can't access anything as a guest, not even the public project. – Arseni Mourzenko Sep 12 '13 at 6:23
  • Is there another Require in there preventing the anonymous access to that /root location? And what do the Allow/Deny rules look like? – Shane Madden Sep 12 '13 at 6:34
  • @ShaneMadden: I misunderstood your first comment. It is answered in the note at the end of my question. – Arseni Mourzenko Sep 12 '13 at 7:23

I built a fresh environment from scratch and played with its configuration, but it appears that the only way is to set everything public by default, and then restrict particular projects explicitly.

This is completely foolish, security wise, especially in the context where lots of projects are created, sometimes not fully automated, making it easy to make a mistake by forgetting to put a restriction. This being said, it also forces to push the automation further, which can only be beneficial.

If somebody wants to play with the settings, I can provide the current configuration used.

  • I think the problem here is that when checking out a sub-directory within the repo, it's expecting to be able to read some items from the root of the repo, which is being blocked... would it be reasonable to have a repo for private projects and a separate repo for public ones? – Shane Madden Sep 12 '13 at 20:08
  • @ShaneMadden: alas, no. Projects are often migrated from private to public (and rarely from public to private). Moving from one repository to another wouldn't be acceptable. – Arseni Mourzenko Sep 12 '13 at 20:37
  • Gotcha. Since the errors are for /root/!svn, maybe you can allow access to there to get the checkouts of subdirectories working. – Shane Madden Sep 12 '13 at 20:48
  • @ShaneMadden: it appears that it has the same result as setting the permissions on /root: as a guest, I can successfully access the public project, cannot access the restricted one, but can access new projects which were not configured. – Arseni Mourzenko Sep 13 '13 at 11:58
  • So it's working aside from needing to have projects default to private? If that's the only remaining problem, we can probably make that would through some creative configuration. – Shane Madden Sep 13 '13 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.