It's certainly possible, I have a similar setup to David (mine is the default setup for Centos):
DocumentRoot /var/www/html/
with the following in my /etc/httpd/conf.d/subversion.conf
file (minus comments):
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
<Location /svn>
DAV svn
SVNParentPath /var/www/svn
# Limit write permission to list of valid users.
<LimitExcept GET PROPFIND OPTIONS REPORT>
# Require SSL connection for password protection.
# SSLRequireSSL
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/svn-auth-file
Require valid-user
</LimitExcept>
</Location>
Do you have SELinux in Enforcing? You might need to correctly set the context of the files in your /var/www/svn location.
The sestatus
command will show you whether you're in Enforcing mode or not. You can (temporarily) use setenforce 0
to switch from Enforcing to Permissive and try again to see if that is the problem.
You want the labelling for the format file to be system_u:object_r:httpd_sys_content_t:s0
(use ls -Z
to see SELinux labels for files). You can fix it using restorecon -R /var/www/svn
.
For further reading on SELinux, I refer you to the Fedora SELinux User Guide
Often, you run actual web applications inside your webserver (php, perl, whatever). This web-apps typically have write-access to some directory inside the document root to upload stuff.
Now, there might be a bug inside your web-app which would allow an attacker to create arbitrary files inside your web-root (and then probably symlinks too). This might even be possible when you don't have an actual upload component, but just the bug. These bugs are not that uncommon that you should ignore them. Especially applications like wordpress have a rather long history of this kind of bugs.
Now that an attacker can create files and symlinks inside your web root, it can let those symlinks point to arbitrary files on your webserver (/etc/passwd
, config files with clear text passwords, ...) which finally could mean that an attacker can download all these files and use the gathered information for further attacks, like dictionary attacks on SSH password, simple authorized access to your database, ...)
If you restrict your Apache to not follow symlinks, this attack vector is much harder to exploit. Another, equally important security measure is to restrict read-access to only absolutely necessary files for the webserver / web application user. You could also use external application server (common with python and ruby applications, but also with fcgi setups) and run this with another user than the core webserver user. If you restrict access to important files between this user and the webserver user, you can gain a rather high security level.
Another alternative would be to chroot your apache to the document root, in which case the operating system would ensure that the Apache processes can access no files outside the document root. Note that this is rather hard to achieve with the packages in common distributions.
Best Answer
Check out the security tips page.
http://httpd.apache.org/docs/2.2/misc/security_tips.html
Since apache opens and reads the log file as root, there is a danger here for abuse. Not sure why you would want a non-root (apache) user to have write access to the files. You can safely grant read access but would suggest that write access only be given to old files that have rotated. Apache is not opening these files when you use logrotate to manage log rotation.