Quote:
Originally Posted by mzh
Dear all
I'm setting up some CGI scripts to be executed by Apache. What I find disturbing is the fact that since the owner of the CGI script is the Apache user
|
There is absolutely no reason why the CGI scripts should be owned by the Apache user, or group. In fact, doing so opens up possible security holes, since Apache -- and thus any remote user -- is technically able to modify the CGI script or program. (For the group, the situation is much murkier. In distros where
/proc/pid/fd is only accessible to the owner user, the group solution shown by rustek should be safe, as long as the Apache user or group does not have write access to that or any of the parent directories. I think.)
Assuming you wish to also restrict the script visibility from other users on that server, you have three choices: The one shown by rustek, another practical one, and the secure one.
The other practical one is to only allow the Apache group access rights to the cgi directories, or better yet, to the virtual host root directory. POSIX ACLs make this trivial, but here is an example using standard Unix access rights model:
Code:
drwxr-x--- root www-data /var/www/
drwxrwsr-x root my-group /var/www/my.site.com/
-rwxrwsr-x my-user my-group /var/www/my.site.com/cgi/script.cgi
Here,
/var/www acts as a choke point, allowing only users belonging to the www-data group.
my-group is the administrator group owning the
my.site.com tree.
my-user is the administrator who created the
script.cgi file. [Administrator groups eliminate the need to chown files when administrator users change. Also, multiple users can modify the same files, as long as they have umask 002 and the site directories have the setgid bit set and are owned by the administrator group; this inherits safely automatically. I also recommend a practice of renaming a file, then copying it back, so the owner user always tells who last modified the file.]
This scheme, and the one recommended by rustek, have one serious drawback: Any user who is able to write a CGI script, will be able to both read (copy) and execute all CGI scripts.
The secure method is using SuEXEC (or a similar mechanism). It means that CGI scripts are run by specific, preferably dedicated (no-login, no-password) user accounts. Each virtual host can run their CGI programs as a specific user and group (see SuexecUserGroup), although non-CGI files will still be accessed as the default Apache user and group. For desired (also preferably dedicated no-login no-password) user accounts, per-user CGI scripts somewhere under
/~user/ can be run as that user (and her default groups). I've written here in LQ and elsewhere how to manage that, while using
mod_rewrite to "relocate" such URLs into any location/URL in any virtualhost on that same server. It is also possible to deny external access to the actual
/~user/ URLs.
The secure method is a bit of work to set up properly, and it requires care. Ffor example, I recommend relocating Apache config directory in /etc, so that updates and newly installed packages do not get their configuration automatically enabled. It also requires a good understanding of the POSIX access model from the server administrator (but fortunately not from the www administrators). (I'm just worried about bugs in Apache proper and Apache modules, and about thinkos in future config changes.)
Hope this helps.
