[Not a bug] When PHP is run as CGI

ZenCart v1.3.7
PHP Version: 5.2.1 (Zend: 2.2.0)
Zend Optimizer Version: 3.2.2
Database: MySQL 4.1.21-standard

I have noticed, on two different Servers when PHP is run as CGI, one will see that big error msg. with the Red background;
"Warning: I am able to write to the configuration file: ... "

This is a bug because the directory/file permissions "are" correct.
Also seems to be a Grandfather bug because osCommerce (any version) gives the same error msg. as well.

Current Solutions are to edit or comment out, either of;

line 313 of /includes/languages/english.php (default install)
define('WARNING_CONFIG_FILE_WRITEABLE', ... ');

or

line 24 of /includes/init_includes/init_header.php
define('WARN_CONFIG_WRITEABLE', 'true');

Can anyone advise as to alternative or better solution?

And let us not get into the pro's & con's of whether to run PHP as CGI or not. Some prefer to and that's simply the way things are. :wink2:

Not technically a bug, but a result of hosting configuration.
Remember, if someone can run a PHP script against your files, it will have all the permissions that PHP has access to ... so ... if running PHP as CGI gives full rights, then ... the rogue script will have full rights.

Anyway, as you mention it, yes, you can tell Zen Cart to ignore the warning:

To override the default behaviour for your unique hosting configuration, simply set up an override for the init_header.php file:

/includes/init_includes/overrides/init_header.php
change line 24 to say 'false':
define('WARN_CONFIG_WRITEABLE', 'false');

granted, my preference and recommendation is "against" running PHP as CGI ... because a number of "other" problems also tend to crop up with unexpected results when using that mode

Many other scripts will not give an error msg. about being able to write to the configuration file. In fact, ZenCart & osCommerce seems to be the only two (that I know of) and, since ZenCart is originally based on osCommerce, it is why I mentioned about it being a "Grandfather" bug. A search at osCommerce Forums showed over 2,000 threads with the same problem. Some could fix it, some could not. I only looked at the first page of the results but none referenced how PHP was being run; as DSO/Apache Mod or CGI.

I understand the situation though, and your reply. I was simply looking to make a thread, here at the ZenCart Forum, that would explain somewhat about the problem and potential solutions. Long as people know; when PHP is run as CGI the error msg. "is not a security issue" and how to correct it, that is what counts.

Are you setting the config files to 444 or 644? With PHP as CGI they MUST be 444.. 644 will throw that error. All the servers I've been on have been set up as php as CGI except for one. All the PHP/CGI ones required a 444, and the only way I could accomplish that was with a php script:

<?php
chmod("includes/configure.php", 0444);
chmod("admin/includes/configure.php", 0444);
?>

name it "chmod.php".. put it in the root..and hit it with your browser.. should take care of those messages. When you chmod via FTP it won't always set it to 444.. normally changes it back to 644 (at least for me.. YMMV on the ftp stuff)

Being as I have 'root' access to the Server, had not thought of trying to change permissions with a script.

Learn something new everyday. :wink2:

:) glad it helped! I have root access as well but try not to use it as much.. mainly because it screws up ownership with php as cgi stuff

DrByte:

Not technically a bug, but a result of hosting configuration.
Remember, if someone can run a PHP script against your files, it will have all the permissions that PHP has access to ... so ... if running PHP as CGI gives full rights, then ... the rogue script will have full rights.

Anyway, as you mention it, yes, you can tell Zen Cart to ignore the warning:

To override the default behaviour for your unique hosting configuration, simply set up an override for the init_header.php file:

/includes/init_includes/overrides/init_header.php
change line 24 to say 'false':
define('WARN_CONFIG_WRITEABLE', 'false');

granted, my preference and recommendation is "against" running PHP as CGI ... because a number of "other" problems also tend to crop up with unexpected results when using that mode

So I just found this thread. I've been having this "no input file specified" issue with php-cgiwrap installed. Removing php-cgiwrap also removes the "no input file specified" error I'd been having. I then checked and changed both config files to 444 and reinstated php-cgiwrap but the "no input file specified" error returned.

DrByte, your solution sounded interesting but when I went to /includes/init_includes, I did not find any file named init_header.php so could not make your suggested change as an override. Has this file been deprecated in version 1.3.8a
Database Patch Level: 1.3.8? Where do I make the change you suggest?

If you're missing the /includes/init_includes/init_header.php file, then you're not using v1.3.8a, or you've lost something. The file was added in v1.3.0, and still exists today.

You are right, I was wrong... the file was in there after all. I can't explain why I didn't see it before but it is definitely in there now.

I've actually chosen to not use php-cgiwrap though for this particular installation. I'd rather not eliminate the warning message because it is important not to leave a config file writeable and I don't want to forcefully disable that warning.