But ScriptAlias here is not necesseray or +ExecCGI is not in the good place ?
I mean with this conf you might run a CGI script anywhere in /home/account/domain/html and so ScriptAlias /cgi-bin/ /home/account/domain/html/cgi-bin/ has no effect. Is it right ?
So the conf that would allow cgi scripts only in /cgi-bin/ should be
There is normaly two ways to define and permit the execution of CGI scripts.
the first way is to define the scriptalias only. With scriptalias Apach will know that ALL scripts in this directory have to be treat and run as a CGI. CGI script can be run in this case ONLY in scriptalias dir.
the second way allow to run CGI else where the scriptalias dir. In this case we have to define one handler and the option +ExecCGI for a directory. The handler tell which file may be run and the +ExecCGI tell that this directory could run CGI scripts for whom there is an handler defined.
So in the default CGI iworx config we have both. All files in /cgi-bin/ will be run as CGI and all files that match the handler in /html/ will be run as CGI.
In our case as in iworx.conf there is an handler like this
it means that ALL files .cgi or .pl in the directory /html/ will be run as CGI.
So my question is why do you allow CGI scripts .cgi and .pl in /html/ and all CGI scripts in cgi-bin by default ?
Wouldn’t it be more secure and reliable to only allow all files to be run as CGI scripts in /cgi-bin/ only by default and let the admin to allow or not the use of CGI with handlers/EXECcgi in /html/ ?
I Tell this because I had to found which account used CGI scripts on one box and which one. At the beginning I thought that list all the contents of /cgi-bin/ dir per vhost would be suffisant. But I quickly realise it was not. With this conf it is very difficult to check which CGI scripts your users use. The only way is to look at suexec.log and try to find the script somewhere in the vhost dir.
lol it is a pascal’s thread. I"ll be best to create a blog
No but seriously nobody is conerned by this ?
When you do shared hosting, it happens you have to check who is running CGI and what CGI is runned. Ok in suexec.log you might list all the CGI ran. But the name doesn"t means it is this one.
I’d really prefer to have a script-alias set to /cgi-bin/ only and nno +execCGI evrywhere in the documenroot.
Like this by default all CGI would to be in /cgi-bin/.
And for me it is an admin decision to give the +execCGI to all the documenroot to one specific account (in my case it’d be to a customer I trust)
It’s redundant and probably becuase we were coming from 1.3.x Apache and then later added in the +ExecCGI. Honestly the +ExecCGI for the whole html directory doesn’t worry me at all. PHP is live for the whole directory and given that PHP doesn’t run under any suexec like mechanism makes it more dangerous in some cases than a CGI script who always runs as the user. You really don’t gain any security by having all CGIs locked to the cgi-bin dir.
Also, in iworx.conf the module mod_suexec is loaded if not already loaded elsewhere.
Ok normaly it should be already loaded in httpd.conf but if it is not this could be false if you use a 64Bits arch. In this last case it should be
and lib64 rather than lib
This was simply a fix for old RH9 boxes that didn’t load suexec under some circumstances and for new installs isn’t really needed.
Thanks Chris to confirm my understands about this.
I completly agree there is no security adds value to have CGI scripts in cgi-bin but my experience is that it is much more easy to find the CGI scripts used per a user.
Recently I had a pbm with an account who ran some proxy CGI script. It take us time to find which user it was and which script it also was. If we had only CGI script in cgi-bin directory we could create a script to scan all these CGI.
That all why I really prefere the cgi-script location has to be a server admin decision. It’s not about security but much more for admin management facility purpose.
I had not noticed that before.