• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

wierd problem with cgi-bin

ZopfWare

Regular Pleskian
I just installed nagios for doing server monitoring and all of a sudden my cgi-bin directories were giving me fits.

I had to install the following to get the nagios app to work:

fping-2.4-1.b2.1.fc2.rf.i386.rpm
libtool-libs-1.5.6-1.i386.rpm
perl-Crypt-DES-2.03-3.1.fc2.rf.i386.rpm
perl-Net-SNMP-4.1.2-0.1.fc2.dag.noarch.rpm

the above were required to resolve dependencies.

Now when I try to run something from my cgi-bin I get the following error:

/home/httpd/vhosts/prescriptionrx.net/cgi-bin/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://www.prescriptionrx.net/login.html

However after a little research I found out that there may be a bug in php when it is used with the Crypt module???

I don't know what has happened.

I found that if I gave my cgi-bin directory the following perms all is fine.

cgi-bin rwx r-x --x
it works again.

I don't understand why the default plesk perms of rwx for owner and r-x for group no longer work.

Why did I have to give e(x)ecute permissions to other to get my cgi scripts to run again?
Would really love to know the answer to this.
 
You're running into this problem because the cgi-bin directory itself is set as a scriptalias. This means that all files under the directory are automatically parsed as though they are scripts. The best place for the .htaccess file you're trying to work with would be to put it in your private/ directory. This will ensure, under all circumstances, no users are able to obtain your htaccess file (increasing your security a bit).

A simple re-write to the script configurations that utilize that specific .htaccess file should allow you to correctly operate your script without running into this error under normal circumstances (i.e. standard permissions).
 
Back
Top