html processed as php - file operations don't work

Hi...A funny thing I noticed:

First, I have .htaccess specifying that .html files should be processed through php, and it has been working for months.

That being said, I have an html file that I am trying to perform a file operation inside (I am trying to programmatically create an html file):
<?
/*some php code*/
$fh = fopen("/home/.ceefer/myusername/mysite.com/subfolder/filename.html", 'w') or die("can't open file");
/*some php code*/
?>

When this code block is inside a file called "test.html" I get the following error:

"Warning: fopen(/home/.ceefer/myusername/mysite.com/subfolder/filename.html) [function.fopen]: failed to open stream: Permission denied in /home/.ceefer/adminsean/mysite.com/test.html on line 3
can't open file"

However if I rename test.php to test.html, it works fine.

Can anyone tell me how I can "fix" file operations within html files precessed as php? Or is it a bug? I don't want to have to rename all of my files (and their references) to .php, neither do I want to have some files as php and some as html.

THanks!

Don't know if this will help...

First, I see you are pointing to the volume location for the file:

In reply to:

---

/home/.ceefer/myusername/mysite.com/subfolder/filename.html

---

The ".ceefer" is the mounted volume where your files are stored.

I am not sure if it is a good idea to use the volume name in your path (others may explain why it is a good thing? I just learned how this is set up myself).

I would use /home/myusername/... . It is a link to what you are using anyway, but volumes are part of the DH controlled configuration. I would not rely on it being "stable". If you are moved to another volume for some reason, your script will suddenly break.

Second, I am wondering if some setting, such as open_basedir is nailing you. Even though both paths lead to the same file, they would not be interpreted the same. One path could be blocked in php.

Just guessing, but worth a look.

Regards,
Rudy

Hi,
Thanks for the tips!

I tried all combinations of paths -- relative paths, paths from root, etc. and all acted the same. My last test was to get to the bottom of it and use the full unix path just to be sure I was doing it right (and not relying on php's path variables).

It definitely appears to have something to do with how these paths are interpreted, or how php interprets the permissions. Problem is, I dont know where to go to alter/check these things...

Well, just for fun I created a script, call it foo.php. It does create a file in the local directory (I just modified your posted code).

What is the minimum .htaccess file which will produce the error if I change it from .php to .html?

Also, to find out what the php environment variables are, create the following bar.php:

<?php
phpinfo()
?>

Point your browser at it and you get a lovely formatted series of charts telling you all of the php variables. I didn't see anything useful. Please don't leave this script laying around. While it is not super-secret (it could almost be considered public knowledge), make the crackers sign up for an account to get this info.

I'm don't know how to get all of the apache variables, maybe someone else has a suggestion.

Regards,
Rudy

Thanks again,

I can get it to work as filename.php but not as filename.html.

Example:

filename: writetest.php

<?
$fh = fopen("output_php.html", 'w') or die("can't open file");
fwrite($fh, "Writing from PHP file works!");
?>

output:

Try:

RemoveHandler .html .htm
AddType php-cgi .php .html
php_flag magic_quotes_runtime off
php_flag magic_quotes_gpc off
php_flag magic_quotes_sybase off
php_flag register_globals off

I don't know if you need all of the other stuff (flags statements), so I left them in. Not even sure if you need the first line, the second one is the key.

I recall reading somewhere in the wiki: At DH, php runs as cgi.

Regards,
Rudy

Edited by oodways on 06/07/07 05:03 PM (server time).

Are you trying to run PHP as a module or CGI? There is a difference. Running as a module means the script is running as 'dhapache' instead of your user. Thus if 'dhapache' does not have permission to write a file.... permission denied.

Another thing you can do is use an absolute path
$filename = realpath('/home/user/domain/output.html');

Because /home/user is a link to /home/.glob/user but the glob part is variable.




openvein.org -//-

@atropos7
Thanks for explaining why this fix works (it is permissions). As Sean wants to write files, he will probably need to run as cgi. I noted the path thrown in the error is always the full real path, even if the fopen specified the shorter linked path.

Just to clear up any confusion I may have caused in my previous post, php at DH can run as either a module or as cgi?

Based on your input, I found this in the wiki. Scroll down to the section on suexec.

@Sean
The article discusses some caveats and requirements for file and directory permissions. Definitely worth a read, as providing file access does open a vulnerability in your site. Anything written becomes executable. Parse any external input very carefully before committing it to a file.

I jumped in on this problem as I think it is a nice way to make the site look static, even if it is really dynamic. That, and I just love a good problem.

Regards,
Rudy

In reply to:

---

Just to clear up any confusion I may have caused in my previous post, php at DH can run as either a module or as cgi?

---

Yes and no. It used to be a configurable option. But naturally the problem is that when one goes to account for resource usage, it is the 'dhapache' user that gets accounted for instead of the customer users. In a shared hosting environment that is not good - one needs to determine which customer is responsible for any abuse of resources in order to maintain performance.

They did not switch it off all at once. Besides removing the option from the web panel, it isn't supported on the newer servers. However older servers may still have it - but to enable it you add a particular AddType or AddHandler directive to an .htaccess file. Don't complain if doing so doesn't work.

This is just a re-hash of a previous discussion at:
http://blog.dreamhosters.com/2006/04/11/end-of-php-as-an-apache-module/#comments


openvein.org -//-