You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ivan Zahariev <rr...@famzah.net> on 2010/01/11 11:05:12 UTC
More strict file permissions for the administrative ".svn" directories
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:
--- ./subversion/libsvn_wc/adm_files.c-orig 2010-01-11
12:47:23.000000000 +0200
+++ ./subversion/libsvn_wc/adm_files.c 2010-01-11 12:48:57.000000000 +0200
@@ -627,7 +627,8 @@
make_empty_adm(const char *path, apr_pool_t *pool)
{
path = svn_wc__adm_child(path, NULL, pool);
- return svn_io_dir_make_hidden(path, APR_OS_DEFAULT, pool);
+ /* Protect the administrative subdir from being accessible by
"others". */
+ return svn_io_dir_make_hidden(path, (APR_OS_DEFAULT & ~(APR_WEXECUTE
| APR_WWRITE | APR_WREAD)), pool);
}
Please let me know what you think. Should I direct this to the "dev"
mailing list? Thanks.
Best regards,
Ivan Zahariev
Re: More strict file permissions for the administrative ".svn"
directories
Posted by Samuel ROZE <sa...@gmail.com>.
Hello,
I use "svn co" like I explain, so I can use "svn update" to simply
update my projects. I think that it can be a good idea to remove read
for "o" but an experimented sys admin should know that .svn directory
mustn't be accessible from the web !
I use Apache and there is my configuration line which send a 404 error
when a HTTP client ask for .svn directory:
RedirectMatch 404 /\\.svn(/|$)
So simple...
Regards,
Samuel ROZE.
Le lundi 11 janvier 2010 à 13:05 +0200, Ivan Zahariev a écrit :
> 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:
>
> --- ./subversion/libsvn_wc/adm_files.c-orig 2010-01-11
> 12:47:23.000000000 +0200
> +++ ./subversion/libsvn_wc/adm_files.c 2010-01-11 12:48:57.000000000 +0200
> @@ -627,7 +627,8 @@
> make_empty_adm(const char *path, apr_pool_t *pool)
> {
> path = svn_wc__adm_child(path, NULL, pool);
> - return svn_io_dir_make_hidden(path, APR_OS_DEFAULT, pool);
> + /* Protect the administrative subdir from being accessible by
> "others". */
> + return svn_io_dir_make_hidden(path, (APR_OS_DEFAULT & ~(APR_WEXECUTE
> | APR_WWRITE | APR_WREAD)), pool);
> }
>
> Please let me know what you think. Should I direct this to the "dev"
> mailing list? Thanks.
>
> Best regards,
> Ivan Zahariev
Re: More strict file permissions for the administrative ".svn" directories
Posted by Ivan Zahariev <rr...@famzah.net>.
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 <rr...@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
>
Re: More strict file permissions for the administrative ".svn"
directories
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jan 11, 2010 at 06:05, Ivan Zahariev <rr...@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