Page 1 of 1

file permissions problem

Posted: Sat May 31, 2003 11:09 am
by Bill H
I am developing an application in which it is essential that it be permissible for the application fo create new files in the "files" directory on the host server. But to do that the directory has to be chmod()'d to 777 after it is created, and my fear is that the average targeted user is not going to be sophisticated enough to do that successfully.

So I am using the following code:

Code: Select all

<?php
$f = @fopen("files/admin.dat", "w");         // for writing, truncated
if ($f == FALSE)
{    chmod("files", 0777);                        // this is line 114
     $f = @fopen("files/admin.dat", "w");
}
fwrite($f, $a);
fclose($f);                                              // continue on to display
?>
but it results in the error that "permission is denied" on line 114

I have tried setting up the upload without the directory and creating the directory (with the proper permission) but have the same problem "permission denied."

Do I have any option here other than writing some lengthy tutorial to the unsophisticated user about unix permissions and how to set them using each of several dozen possible protocols (ws_ftp, etc) and causing nost potential users to say "to hell with it"?

Posted: Sat May 31, 2003 9:15 pm
by McGruff
Could be the current directory isn't parent/files - debug using getcwd()?

Posted: Sun Jun 01, 2003 12:17 am
by Bill H
Hmmm. Excellent thought. I will try that tomorrow (my brain is dying this late at night) and post results. Thanks for the input.

The next morning - that was such a nice thought, but:

Code: Select all

<?php
echo getcwd();
$f = @fopen("files/admin.dat", "w");         // for writing, truncated
if ($f == FALSE)
{    chmod("files", 0777);
     $f = @fopen("files/admin.dat", "w");
}
?>
produces:
/data/web/72590/www/utility/family
Warning: chmod failed: Operation not permitted in /data/web/72590/www/utility/family/admin.php on line 116

Posted: Sun Jun 01, 2003 9:14 am
by Kriek
At your UNIX prompt, assuming you are running apache enter the command ps -ef |grep httpd, you should see the httpd apache process, and who owns it. Typically this is the user nobody. Your file needs to be owned by the user that owns the httpd process. See chown() and chgrp() (super-user privileges)

Posted: Sun Jun 01, 2003 10:24 am
by Bill H
So "admin.php" is not the owner of the "files" directory and therefor cannot change its permissions.
But only the "superuser" (which is not admin.php) can change the owner.
That explains why I can't make my application work.
I appreciate any input that is offered, but I don't see this leading to any kind of solution.
Or if it does, I'm not sharp enough to spot it without further input.

Posted: Sun Jun 01, 2003 7:03 pm
by McGruff
I'm also having a similar problem with a page-caching script.

If I mdir() in php (need to chmod parent 777 first) I can write files to the directories np - but I can't use my FTP program to delete files or upload images to the directory.

If I use my FTP program to create a directory, I can't write files to the directory with my php script.

Looking at directory info (dirinfo command in WS FTP) you can see that folders created by WS FTP are listed as "ftp_login_name" "users" and folders created by php are listed as "php" "php" (fileowner returns 498).

So, next I tried to chown(getcwd(), 498) folders created with FTP but got an "operation not permitted error".

Just how DO you get chown to work?

Alternatively, how can I get my FTP program to add files to a php/php directory? that would also solve my problem.

Posted: Sun Jun 01, 2003 9:47 pm
by McGruff
This might depend on the host setup:

Create the directory with a php script and mkdir($directory, 0755). The parent will probably need to be chmod'd 777 first - but you can change it back to 755 once the directory is created.

I found that php scripts wouldn't write to a folder unless it's php/php (see dirinfo command in something like WS FTP) as opposed to ftp_user_name/users - what you get when you create a folder with an FTP program.

However, my FTP program can't delete or upload to a php/php folder.. :roll: If, for example, the files have a series of <img> links (mine did) put these in another folder created with your FTP program (not a php/php directory!) so you can upload them easily.

I don't know if that will work for you but it did the trick for me.

Posted: Sun Jun 01, 2003 11:30 pm
by Bill H
The parent will probably need to be chmod'd 777 first - but you can change it back to 755 once the directory is created.
Yeah, but that leaves the problem of chmod()ing the parent. No solution. If I could do that I could chmod() the directory.
:x

Posted: Sun Jun 01, 2003 11:41 pm
by SBukoski
I think he means to chmod the parent folder in WS_FTP, for example, to 777. Then have the PHP script create the folder so it will be there when files are uploaded. That way the script itself will have the permissions to work in that folder.

After the folder is initially created you chmod the parent directory back with your favorite FTP program. This should only need to be done once (hopefully). Once the folder that the PHP script will be working in has been created by the script, all should be good.

Posted: Mon Jun 02, 2003 12:07 am
by McGruff
Rgr: chmod 777 the parent directory with your FTP program then, if your system behaves like mine did, you can make a "php/php" directory with a mkdir() script: php scripts should be able to write files in it (even after you chmod the parent back to 755).

I only discovered a lot of this tonight so sorry if it's a bit garbled.

Wish the manual explained all this in more detail.. Maybe some kind person will help us out :)

Posted: Mon Jun 02, 2003 8:45 am
by Bill H
Back to my original post: the application is intended for installation by unsophisticated users who are mostly not well versed in the process of uploading files to the internet. Many of them use (for instance) Cox with a limited webspace and some sort of limited upload protocol for placing files on the server. When I say in the directions "the 'files' directory must be chmod()'d to 777" they are lost and decide that they are unable to deploy the application. Testing has shown that two out of three are thrown by that requirement.

This means that this simple application is unavailable to the very people for whom it is designed. Since it is freeware there is no way I can afford the support that will be required if I distribute it with that requirement. If I cannot eliminate that requirement the application remains undistributed.

No monetary loss since I intend to distribute it as freeware. But I have had a number of people tell me that families would find it useful. It's a family gift registry which I implemented for my family and they love using it.
:cry:

Posted: Mon Jun 02, 2003 12:08 pm
by McGruff
Did you try chown and chgrp? (Didn't work for me I'm afraid).

Php fns: fileowner, filegroup and is_writable can get some information about the parent directory.

Also, if you create a directory with mkdir() (assuming that behaves the same as in the tests I carried out and creates a php/php folder) you can run fileowner and filegroup on that to see what values you need to feed to chown - assuming chown will work at all.

Coud really use some expert help - anyone?

Posted: Tue Jun 03, 2003 8:01 am
by Bill H
Cannot create a directory with mkdir() because the directory we uploaded into (containining admin.php) would need to be chmod()'d first. And we're back to instructing the user to chmod() a directory.