I'm having some trouble with fopen and my permissions. The web root is in a jailed user directory...if that makes any difference.

Meet the players:

Me - a LAMP noob.

php.ini - allow_url_fopen = on

The script - home/username/web/public/fopen.php

<?php
// change to the cdfolder
chdir(cdfolder);

// create the file name
$filename = "filename.php";
 
// create a new file by using fopen
$filehandle = fopen($filename, 'w') or die("cannot create file");
?>

The structure, ownership, and permissions -

/home                root:root         755            
/home/username             root:root         755
/home/username/web          username:username   775
/home/username/web/public      username:username   775
/home/username/web/public/fopen.php   username:username   774

/home/username/web/public/cdfolder   username:username   774

Needless to say the script is not able to create the php file in the cdfolder. Any ideas what I'm missing here or how my permissions are wrong?

_________________
I'm completely new to the LAMP stack.

The permissions go owner-group-everybody (the three digits in 774).

Your folder is owned by "username" and belongs to group "username". Your copy of PHP is probably running as someone else (nobody, www-data, etc). Your folder permissions are 774, which is:

owner: read, write, execute
group: read, write, execute
everybody: read

The permissions that you've set on that directory only allow PHP (which would fall under "everybody") do not allow writing.

One solution might be to change the group of the directory to match that of PHP. That's what I do often, although I'm no security expert.

What Guspaz said would work, I've done it before, the other option is to run PHP under fast cgi so it would run as the owner of the file.

Are you sure you need this ? (Your code snippet shouldn't, at least.)

Yep. PHP seems to be running as www-data. I changed all the permissions to 777 to test it out and sure enough the filename.php file was created and the owner was www-data.

I’ll try changing the group of the directory to match php like you suggest and give that a shot. Also, I’ve read a little about running php under fast cgi, but haven’t tried it yet. Is it considered a ‘best practice’ to run php under fast cgi?

As for the the allow_url_fopen I guess you’re right, I was just trying anything and everything with ’fopen’ in the name.

Thanks for your info everyone this really helped me out!

_________________
I'm completely new to the LAMP stack.

Egads. Don't forget to put it back.


allow_url_fopen lets you do:

$fp = fopen("http://example.com/file.txt", "r");
$data = file_get_contents("ftp://example.org/pub/file.bin");

Without it, PHP would not allow URLs in these functions.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

Using apache..no it's horrible to configure, using nginx/lighttpd sure! I personally do nginx proxying back to apache running mod_php, nginx does all the static stuff, apache does the rest.

chgrp www-data /path/to/cdfolder && chmod g+w /path/to/cdfolder should do the trick, unless you want to go the fastcgi route.

Fastcgi is the best way to run PHP under specific users. But as obs said, Apache + fastcgi = h3ll. If you want fastcgi, try nginx or lighttpd.

Turning allow_url_fopen on is often considered a security risk. If you ever need to fetch remote resources, use appropriate extensions such as curl.

In the context of this conversation, I guess you mean running "suexec", so that PHP processes run with the userid of the account owner?

There are pros and cons to this. It's commonly done on shared hosting servers as it makes it much easier for administrators to identify abusive users (at least abusive PHP users). It can also provide slightly better isolation between user accounts.

But there's a downside. As the PHP process has "write" permissions anywhere in the user account, an exploited process can wreak severe damage. For example, an exploited app installed in /forum could easily overwrite any/all files in the user account inside and outside the /forum directory. The same exploited app running under mod_php could only write to places where you'd given it explicit permission.

If your Linode resembles a shared hosting server then you might want to consider a suexec setup. If not then I don't think it's a good idea. But that's my opinion