|questions about php filesystem permissions under *nix|
unable to use mkdir() in webroot; permission denied
i'm writing a small web app, and it needs to make a directory (if the directory doesn't already exist) and a file inside that directory (if the file doesn't already exist) and then write to that file. here's a snippet of the code i'm using to do this:
if (!is_dir($directory) and!mkdir($directory, 0777) )
// throw an error
if (!$filehandle = fopen("$directory/$file", 'a+') )
// throw an error
this code works on my windows box (running Apache/2.2.4 (Win32) and PHP/5.2.1 on WinXP Pro SP2), but fails (with a "permission denied" error) on my production server (running Apache/1.3.37 (Unix) and PHP/5.2.3 on Red Hat 9).
i know this is because the web user ('nobody', in this case) doesn't have sufficient privilege to write to this part of the filesystem, and that i can make it work by chmoding docroot to 777 (which i'd rather not do for the obvious reasons).
the other thing is that i want to distribute this web app, and i want to make it as easy as possible to install and run (ideally, the user should just be able to upload the program, open it in a browser, and and run it).
i tried system()ing and exec()ing the mkdir call, and neither of those worked, either (i didn't expect them to, since the script that was calling them was still running as the web user), but then, just for kicks, i wrote the same basic function in perl and stuck it in the cgi-bin and it worked (which i'm assuming is because the server is running suexec).
my questions (finally):
1) is there any way around the php user permissions limitation (barring end-user interventions like chmoding docroot 777)? i've been looking for a couple of days now, and haven't come up with anything.
2) is suexec (if that is in fact why the perl script has sufficient privilege to run mkdir in docroot and php doesn't) pretty widely available? i know it's not enabled by default in apache 1.3; what i'm wondering is, is it something that most end-users are likely to have enabled on their servers?
I might have misunderstood (easily done!), but why do you need the end-user to perform a chmod? Why not just use chmod() to set and reset the required perms programatically?
|I might have misunderstood (easily done!), but why do you need the end-user to perform a chmod? Why not just use chmod() to set and reset the required perms programatically? |
thanks for responding, darren.
the reason that having the end user chmod docroot is a possible solution is because (generally speaking) they "own" that folder, and so have sufficient privilege to write to (and chmod) it. a php script runs as the web user ('nobody' on many *nix machines), and, for security reasons, the web user doesn't have sufficient privilege to write to docroot (or to chmod it, either).
having the end user change the permissions on docroot to 777 would make it world-writable (and world includes the web user), so that would allow the script to work, but it's an unacceptable solution, both from a security standpoint and from a convenience standpoint: the end user would have to chmod docroot to 777 every time they wanted to run the program, and then chmod it back, or leave their web document tree world-writable.
I accomplished something similar. But only used this solution temporarily, as it could be very dangerous (security wise). I would recommend devising a new idea to how your user's data is stored.
I wrote a separate script that would chmod the webroot directory (public_html) to 777, make the needed directory, then chmod the webroot directory (public_html) back to 755.
If the script ever stopped running or was interrupted at the wrong point, your webroot folder would be open to hackers or anyone else who want's to add a new index file or delete your folder contents.
Maybe contain everything in a subfolder a level down from the webroot folder, and use an htaccess rewrite to make the URLs appear in the root.
The data would be stored as:
but is accessible by going to:
I would advise against this method. But hey, I never had any trouble with it. I'm just generally paranoid about any possible security exploits.
thanks, JB. :-)