PHP Permissions Problem

@JonaOct 04.2006

[font=trebuchet ms]Hi everyone, long time no see.

I’ve got a PHP app that I wrote that requires a CHMOD of 777 for file operations to take place, since PHP isn’t the original creator of said files. However, I’ve discovered some security concerns with this and wrote a patch program to replace all current 777 directories with 755 ones, but have PHP recreate them. (Hence, the files are no longer insecure with the 777 CHMOD settings.) I have this working fine, however there is one problem: in order for the patch to run, its parent directory must also have CHMOD settings set to 777. If the app is installed on the root directory of a host, there is no folder above the root that can be set to 777, so the patch cannot run; is there any way around this? Is there a way to run a patch that copies all 777 folders, deletes them, and renames the copies as the originals in order to give PHP full access to them without needing 777 permissions, without setting the directory in which the patch program is run to 777?[/font]

to post a comment

PHP

24 Comments(s) _↴

@JonaauthorOct 04.2006 — #*bump*

@chazzyOct 04.2006 — #you wrote the patch? or someone gave it to you?

it sounds like you should just remove the part about it chmodding the parent directory.

@JonaauthorOct 04.2006 — #[font=trebuchet ms]I wrote the patch myself. It works perfectly, but only when it’s in a directory that has 777 perms. I can’t make the perms on the server’s root directory 777, so I can’t run the patch on the root directory of the server. I am looking for a way to get the patch to work without needing its parent directory to have 777 perms.[/font]

@chazzyOct 05.2006 — #i doubt i could tell you that without actually seeing what the patch is doing.

@JonaauthorOct 05.2006 — #[font=trebuchet ms]The patch looks at the filesystem and creates a list of directories below it (so if the patch is in root, all the directories on the server are added to the list). Then it takes those directories, creates new dirs (with _temp appended to the end of the original names), moves the files that are in the dirs to the _temp dirs, deletes the old dirs, and then renames the _temp dirs to what the originals were. It’s a run-around that gives PHP full access to the files without needing to set 777 perms on the folders themselves.

If you want the PHP, I could probably post the file as an attachment on the forum here, but it’s probably too long to actually post as a reply. (It isn’t complicated at all, just somewhat lengthy.)[/font]

@JonaauthorOct 05.2006 — #[font=trebuchet ms]Here’s the patch file.[/font]

[upl-file uuid=a3c3c404-b915-49e6-b9ca-7f56ce9df2d3 size=1kB]gbcms_patch.zip[/upl-file]

@chazzyOct 05.2006 — #I just want to verify, in all cases you've run this thus far, getcwd() has worked properly, right?

if so, there's nothing stopping you from following line 55 with a new line. here's 55/56

[code=php]
 $curDir = getcwd();
 chmod($curDir, 0777);
 [/code]

by the way, if the app is installed as "/gbcms" then the parent is /. I'm not sure if you're saying that the app is installed in /gbcms or in / though. i think you'll have to add a check if this is really a problem.

since it looks like your script is only making directories as subdirectories to $curDir, you should be ok.

@JonaauthorOct 07.2006 — #[font=trebuchet ms]When I run chmod() on anything, I get a “permission denied” error. That’s the purpose of this patch to begin with (in addition to giving PHP permissions without needing 777 perms). I have to set the perms of the dir that the patch is run in to 777 before running the patch as well, otherwise the script breaks, and I have to do it via the HTTP cPanel or FTP. I can’t do it with PHP, as I said, because of the permission denied error.

And yes, I was saying that the main issue is when I run the script on /. There doesn’t seem to be any way to set the permissions on / for PHP to run this patch.[/font]

@chazzyOct 07.2006 — #unfortunately, I don't see anyway around the setting permissions on /. this might be one of those times to list requirements for running the script (ie, don't install in /). most hosts have this locked.

just wondering, have you checked user ownership on the files/directories?

@JonaauthorOct 07.2006 — #[font=trebuchet ms]If you mean by using chown(), yes. I still get a permission denied error, unless the parent directory is CHMODded to 777. There appears to be no solution.[/font]

@netbuddyOct 08.2006 — #Have you tried other values, this explains what the chmod settings so you can try alternative settings to see which one allows your script to function http://www.htmlite.com/php042.php

@JonaauthorOct 08.2006 — #[font=trebuchet ms]Thanks Netbuddy, but my problem is slightly deeper than that. I understand CHMOD and how to use it, this is beyond that realm of simplicity.[/font]

@netbuddyOct 08.2006 — #Have you attempted to telnet the permissions, you may have permission to change them via telnet, it may be a security consideration enforced by the host to stop hijacks and vandals breaking into your site and stop outright robbery of site scripts.

@chazzyOct 08.2006 — #Jona

I guess my last question is who owns / in these cases? Is there anyway you can get (the user, the host, etc) to change ownership of / to nobody?

@netbuddyOct 08.2006 — #What platform is the servers running on, do you know?

@JonaauthorOct 10.2006 — #[font=trebuchet ms]The software is used across a variety of hosts and servers, so the solution must be platform-independent. I tried changing the permissions of / on a dedicated server, and the patch still fails.

I can only change ownership via PHP, but I need a chmod of 777 in order to perform that action. Giving “nobody” ownership of / would be a severe security hole, though I suppose I could quickly change ownership back to that of the user in the same way that I would change the perms from 777 back to 644.

I have done some research and it looks like I’m at a dead end. I think the only other possibility at this point would be to figure out how to get PHP to operate under simulated 777 conditions without actually needing to change the perms of the directory the patch is run in. I am doubtful that’s possible, though.[/font]

@netbuddyOct 10.2006 — #I dont know what to say, it really sounds like theirs issues with ownership.

Unless the host or hosts who dont allow for chmod should allow telnet, if telnet doesnot work, you will need to talk to the various net admins to ask them WTF is going on as you should not experience any issues if your domain accounts are corretly set up on the host.

I do think that the problem is with the hosts, you say that the scripts worked fine before and all of a sudden they dont work anymore, IM pointing my finger at the host.

I would tell them your requirements, thell them what the problem your experiencing and ask them what they are doing to resolve it as you need to be able to use PHP, so what are you paying them for? and dont be bashful or shy, come right out with it, your paying them (IM assuming) or if it gets too extreme you may have to offer the net admin outside for a chat man to man... ?

@JonaauthorOct 10.2006 — #[font=trebuchet ms]Thanks. The script still works fine, but only in a directory. When it is run on the root level directory (/), it breaks and I get a number of permissions errors. I don’t think that the host is the problem, but I can talk with them and see if they can provide any insight.[/font]

@sridhar_423Oct 10.2006 — #a dangerous script to even test.. :eek: i dont own the server on which i'm working

if you're facing problems for creating copies when its in the root directory, did u try moving/copying the patch to some sub-directory(using shell_exec) and then starting the whole process using shell_exec again.. shell_exec("php $curDir/$someDir/myPatch.php")

create the files of the parent dir in some special sub-directory when the above process is followed or else the same process

[B]i'm not at all sure whether it'll work or not. give it a try[/B]

@JonaauthorOct 10.2006 — #[font=trebuchet ms]It’s dangerous to test the shell script, is that what you’re saying?[/font]

@sridhar_423Oct 11.2006 — #no .. i mean its dangerous to execute the patch on my root directory though it works fine, everything will be white-washed..though we take backup everyday.. but if something odd happens.. it can be very serious .. tats what i meant

i'm not saying u r script wont work .. i'm saying i'm afraid to execute that patch.

@JonaauthorOct 12.2006 — #[font=trebuchet ms]Yes, debugging the script was difficult, as a backup had to be restored each time it failed. If a directory had 777 perms but its subdirectories had 644 perms, the files in those subdirectories would be deleted.[/font]

@bokehOct 12.2006 — #Jona, the problem is that your host is set to run PHP (Apache) as "[I]nobody[/I]" or some other common user. The reason the directory needs to be 0777 is because since apache is not the directory owner (you are) it must be set to a permission level so relaxed that non owners can write to it. The unfortunate side effect is that anyone with access to the server can also write to that directory (very insecure). Two option that come to mind are the following: either use PHP to FTP to the directory you wish to write to using your login details or move to a server running [URL=http://httpd.apache.org/docs/2.0/suexec.html]SuEXEC[/URL]. This feature provides Apache users the ability to run CGI and SSI programs under user IDs different from that of the calling web-server.

@JonaauthorOct 13.2006 — #[font=trebuchet ms]Thanks, Bokeh. I’d read about SuExec, but that isn’t an option in our particular case. I also thought about using FTP through PHP, but that would require an FTP user/pass, and we sort of didn’t want it to come to that. Thanks for letting me know what options I have, though.[/font]

Also in #PHP _↴

Alter many files, all with same variable in them pulling file from other web site Converter - Doc/PDF to Html

Success!

Help @Jona spread the word by sharing this article on Twitter...

Tweet This

PHP Permissions Problem

24 Comments(s) _↴

Also in #PHP _↴

Success!

Social

Version

PHP Permissions Problem

24 Comments(s) ↴

Also in #PHP ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

24 Comments(s) _↴

Also in #PHP _↴