php fopen permissions ?

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 - allowurlfopen = on

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

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?

8 Replies

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.

@eekeek:

php.ini - allowurlfopen = on

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 allowurlfopen 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! :-D

@eekeek:

Yep. PHP seems to be running as www-data. I changed all the permissions to 777 to test it out
Egads. Don't forget to put it back.

@eekeek:

As for the the allowurlfopen I guess you’re right, I was just trying anything and everything with ’fopen’ in the name.
allowurlfopen 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.

@eekeek:

Is it considered a ‘best practice’ to run php under fast cgi?

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 allowurlfopen on is often considered a security risk. If you ever need to fetch remote resources, use appropriate extensions such as curl.

@eekeek:

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?

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 :)

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct