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 <rrdtool_at_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
>
Received on 2010-01-11 16:02:34 CET