From the security point of view, it is not really a good idea to setup web pages with the same user of Apache. The Apache user should be able to read the web pages, but not write to them.
As such, in the standard configuration, it is normal for the web structures to be readable by all, and when there is a need to write, normally to be writable by the Apache user, which is a security nightmare.
One of the strategies to avoid that is installing/using mod_ruid2. https://github.com/mind04/mod-ruid2
As for Debian, it is enough to do:
apt-get install libapache2-mod-ruid2
Please do note the Apache default user varies with the distribution. In Debian, it is www-data, in RH/CentOS it is apache, and in SuSE, wwwrun. I will refer to it from now on as the Apache default user.
If you do not define any directives in a vhost, it will behave in the traditional way; otherwise the behaviour will be changed.
The idea of it is having a process running in the vhost with the user that has rights to the vhost, and as such, the files will have that ownership, and as you wish, other users won't be able to read them. Normally you define a user per vhost.
In the Virtualhost or Directory directives in a vhost, you define the user and group which will be active for that directory. The user:usergroup is what will be the effective permissions Apache will use when accessing the Virtual host/directory, and as such, any user that belongs to that group will be able to write/see the directories.
RUidGid user usergroup
As such, when writing the directories, now the files can be created as 660 with the ownership of user:usergroup if they are managed by a group of users. Likewise, the files can also be created by another user with permissions to read for the world; however for writing, it won't be the Apache default user, but rather this other user.
The advantages of mod_ruid2 are then:
- in a virtual hosting housing environment, users can't read other users' files;
- in a single user, you can still create files as yet other user, and neither the Apache default user, nor the ruid2 user will be able to overwrite them
- more importantly, the written files will be now done with the ruid2 user, and not any more globally with the Apache default user.
From the github page:
ABOUT mod_ruid2 is a suexec module for apache 2.0, 2.2 and 2.4, based
on mod_ruid and mod_suid2
-it runs only on Linux because only the Linux kernel has implemented the required process capabilities.
-it has better performance than mod_suid2 because it doesn`t need to kill httpd children after one request. it makes use of kernel
capabilites and after receiving a new request suids again.
-there are some security issues, for instance if attacker successfully exploits the httpd process, he can set effective capabilities and
setuid to root. i recommend to use some security patch in kernel
(grsec), or something..
-there are two main operation modes: stat and config
1. config is default, you must define uid and gid. If no [ug]id is defined the default user and group are used.
- stat httpd setuid and setgid to uid and gid of requested filename(script)/directory this is good if you use mod_vhost_alias
for virtual hosting
1. download and install latest libcap from here
2. run /apachedir/bin/apxs -a -i -l cap -c mod_ruid2.c
3. configure httpd.conf
4. restart apache
CONFIGURE OPTIONS: RMode config|stat (default is config) RUidGid
user|#uid group|#gid - when RMode is config, set to this uid and gid
RMinUidGid user|#uid group|#gid - when uid/gid is < than min uid/gid
set to default uid/gid RDefaultUidGid user|#uid group|#gid
RGroups group1 group2 - additional groups set via setgroups @none -
clear all previous defined groups.
RDocumentChrRoot - Set chroot directory and the document root inside
ServerAdmin [email protected]
RDocumentChRoot /home /example.com/public_html
RMode config # unnecessary since config is the default
RUidGid user1 group1
RMode stat </Directory>
RUidGid user2 group2
RGroups groups1 </Directory>
RUidGid user3 group3 </Directory>
RUidGid user4 user4
RGroups groups4 </Location>