Home : Linux : Servers : Apache :

Scripts

Suexec

From Apache docs

provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

What it does is limit those programs, and their targets, to the DocumentRoot tree of the VirtualHost running them. Ownerships must match and permissions can/should only be writable/executable by the user/group the VirtualHost is running as.

In 1.3 I used 'UserGroup user group' in my VirtualHost block and all script and page permissions could be reduced to n00 permissions.

In 2.0 this has changed a bit. Its now 'SuexecUserGroup user group' and it appears Suexec now only applies to scripts, i.e. I now need pages to be 644 (rw/r/r).
[ comment | link | top ]

ExecCgi

Pretty much all the Apache docs say is:

"ExecCGI    Execution of CGI scripts is permitted."

If you include the 'Options ExecCgi' for a <directory /foo> that isn't defined as a ScriptAlias for a <VirtualHost> Apache falls back to the 'AddHandler cgi-script' directive i.e. you can only execute scripts with those extensions (e.g. foo.cgi or foo.pl).

e.g. I have a private directory with my O'reilly books and a search script in a cgi-bin to search them. I added a <Directory /home/dave/public_html/oreilly/cgi-bin> with Options ExecCgi. The only cgi-script AddHandler I had was .cgi and the script is search.pl, it didn't work. When I changed the script to search.cgi everything worked (I've since added .pl).
[ comment | link | top ]

ScriptAlias

From Apache docs:

"The ScriptAlias directive has the same behavior as the Alias directive, except that in addition it marks the target directory as containing CGI scripts."

Any file with proper permitions can be executed in a ScriptAlias directory (unlike the ExecCgi option, where only files with extensions defined in AddHandler are executable).
[ comment | link | top ]

ScriptAliasMatch

From Apache docs:

"This directive is equivalent to ScriptAlias, but makes use of standard regular expressions, instead of simple prefix matching. The supplied regular expression is matched against the URL, and if it matches, the server will substitute any parenthesized matches into the given string and use it as a filename. For example, to activate the standard

/cgi-bin, one might use:

ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1"

I don't know how /~user/cgi-bin/ is typically handled. There is a UsrDir module, set to public_html by default, that handles any /~user/ request but I haven't seen an equivelant for /~user/cgi-bin/ so I'm using the following:

ScriptAliasMatch /~(.*?)/cgi-bin(.*) /home/$1/public_html/cgi-bin$2

which allows any user to have a /public_html/cgi-bin/ and execute scripts from http://domain/~user/cgi-bin/

...while you cannot use regular expressions with ScriptAlias you can use wildcards, i.e. we can do the above much simpler with ScriptAlias

ScriptAlias /home/*/public_html/cgi-bin/

('*' matches any sequences of characters)

One could add the ExecCgi option to the <Directory /home> which would allow scripts to be run anywhere in /home and down. I beleive a number of servers do this but I see no need to do so and would rather see script usage limited to cgi-bin's.

Using ScriptAlias or ScriptAliasMatch will allow any script to be run, ExecCgi will be limited to scripts with extenstions (unless its also a directory covered by a ScriptAlias or ScriptAliasMatch) i.e. the

AddHandler cgi-script .cgi .pl

One, probably minor for most, advantage of not putting ExecCgi in <Directory /home> is that you can link to live scripts and view them as text in a directory outside of your cgi-bin (public or private directory/viewing).
[ comment | link | top ]

Back to: Apache