Let's not turn this into an Apache discussion :) The Apache config is pretty clear. I use it myself too. But what if someone makes a symlink "evil -> ../../../user2/.svn" ? This cannot be catched by the URL rewrite filter because the URL would look like "http://example.tld/evil/text-base/db-config.php.svn-base". Even if "db-config.php" itself is not readable directly by the web server, the ".svn" copy might be and this is a security risk which you cannot completely circumvent by URL rewrite rules. (P.S. I know there is "SymlinksIfOwnerMatch") (P.P.S. URL rewrite rules have a slight performance impact and are not always inherited the way we expect).
That's why I proposed to use the standard file permission bits. They cannot be fooled by symlinks, wrong web server configs or anything similar. Only by operator's mistakes but nothing can save you from this. Back to my original question - shouldn't ".svn" administrative directories be inaccessible by "others"? Just like OpenSSH requires that its per-user config directory ~/.ssh is writable only by its owner and nobody else. Cheers. --Ivan Andy Levy wrote: > On Mon, Jan 11, 2010 at 06:05, Ivan Zahariev <rrdt...@famzah.net> wrote: > >> Hello guys, >> >> Many developers checkout the working tree directly into the web server's >> public folder, and this imposes a security risk. Anyone can then point >> the URL of their browser within the ".svn/text-base" directory, for >> example, and access sensitive data such as previous versions of a file, >> or even the source code of it, because of the ".svn-base" suffix in the >> filename. This is described in more details at >> "http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/". >> I know that "svn export" exists and this is the way to checkout the tree >> properly and safely, but this is an extra step which developers have to >> do, and you know that extra steps are usually skipped, if they could be >> skipped. >> >> Nevertheless, I see no valid reason for the administrative ".svn" >> directories to be world-wide accessible; correct me if I'm wrong. That's >> why I propose that SVN creates these ".svn" directories with file >> permissions which disallow "others" to enter these directories. Here is >> the proposed patch against the source code of Subversion 1.6.6: >> > > Why not just configure your webserver to return a 404 error on > requests for directories named .svn? > http://www.google.com/search?q=svn+directory+404 >