LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   Permissions for CGI scripts (https://www.linuxquestions.org/questions/linux-server-73/permissions-for-cgi-scripts-887313/)

mzh 06-20-2011 06:55 AM

Permissions for CGI scripts
 
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, it is not possible for me working under my user to edit the script unless I either edit it with sudo or chmod it to 777, which I believe is not advisable.

What is the clean way to do this?

Thanks for any hints on this.

rustek 06-20-2011 07:37 AM

chown youruser:www-data cgifile
chmod 750 cgifile

chown youruser:www-data cgidirectory
chmod 750 cgidirectory

or chown youruser:youruser chmod 755

mzh 06-20-2011 09:24 AM

Quote:

Originally Posted by rustek (Post 4390705)
chown youruser:www-data cgifile
chmod 750 cgifile

chown youruser:www-data cgidirectory
chmod 750 cgidirectory

or chown youruser:youruser chmod 755

hey, thanks for the feedback.

Nominal Animal 06-20-2011 08:09 PM

Quote:

Originally Posted by mzh (Post 4390673)
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.


All times are GMT -5. The time now is 10:39 AM.