Donna
|
| Posted: 05/20/2002, 7:08 AM |
|
I have successfully uploaded files using Alex's File upload (gallery application). I'm using PHP w/ templates.
When I delete a record from the database, the uploaded file is not deleted along with the record. Furthermore, if I use my ftp program I still can't delete the file and receive a "permission denied" message. I should be able to erase any file desired from the directory. Does anyone know what is causing this and how to resolve it?
Thanks!
|
|
|
 |
Donna
|
| Posted: 05/20/2002, 9:56 AM |
|
I notice that the user folders the php code is creating is suppose to set the folder attribute to 777. But instead my folders are being created with 755. I'm using php w/templates and suspect that's the problem. The code was written for non templates....
//Create '$UserName' folder if it does not exist
if (!file_exists("users/".$username)) {
mkdir("users/".$username,0777);
}
Does this sound like the problem to you guys? If so, how should I change the code above?
|
|
|
|
DaveRexel
|
| Posted: 05/20/2002, 11:35 AM |
|
Donna,
I suggest trying the excellent free WS_FTP LE.
Connect to your site and locate the folders you need to change permissions for.
Right click and choose CHMOD to change permissions for files and folders.
Other FTP programs have similar functions and theres always the command line for the brave.
Setting the wrong permissions can be disasterous so please be careful.
Hope this helps
Dave
|
|
|
|
Donna
|
| Posted: 05/20/2002, 12:00 PM |
|
Hi! Dave,
I tried using my normal ftp software (bullet ftp) but these particular folder's won't allow themselves to be changed. OUCH!!! It doesn't make sense. I can create new folders in the same directory and have them set to 777. But the folders that the php script created are 755 instead of the requested 777, and I'm locked out from making any changes to the user folders or the files. Has anyone else had this problem with the script?
http://www.gotocode.com/UserImages/wake/PHPUpload.zip
|
|
|
|
schaeff
|
| Posted: 05/20/2002, 12:16 PM |
|
Probably those files and folders are owned by the uid the webserver runs under. Ask an administrator to remove them.
From then on a mask of 777 should do the work.
|
|
|
|
Donna
|
| Posted: 05/20/2002, 12:30 PM |
|
Hi!
I'm not familiar with that term. Could you please elaborate? Is this php code that I should use in place of the existing uploadresult.php/open event?
Would you be so kind as to provide an example of it's usage (the code)?
Thanks!
|
|
|
|
DaveRexel
|
| Posted: 05/20/2002, 12:55 PM |
|
Donna,
Schaeff is right. After your admin has deleted thos files you will be able to create, delete them as usual in your programs, show your admin Schaeffs message so they will know what you need done.
Hope this helps
Dave
|
|
|
|
Donna
|
| Posted: 05/20/2002, 1:50 PM |
|
I sent the previous messages to my web host and while waiting for a response I did a test. Could you please tell me if my understanding is correct based on the info provided above?
#1 - The folder "users" is probably being used by the web host and that is why there is a permission problem.
#2 - If so, the web host can do something with mask 777, after deleting the folders and it should work. Does this mean everytime a new user folder is created, the web host will have to get involved?
Finally, if #1 is correct, my test would indicate that the problem lies elsewhere. I replaced the name of the folder to be created with the name "myusers" to avoid any conflict with the host. But the same problem still exists. Please forgive my many questions. I'm just trying to understand what you guys are telling me.
Thanks,
Donna
|
|
|
|
DaveRexel
|
| Posted: 05/20/2002, 2:57 PM |
|
http://catcode.com/teachmod/
http://bruce-hamilton.com/tutorials/chmod.shtml
has detailed CHMOD pages
see user permissions tutorials
http://www.perlfect.com/articles/chmod.shtml
|
|
|
|
schaeff
|
| Posted: 05/20/2002, 3:15 PM |
|
It's basically like this:
On Unix/Linux systems each file and directory is owned by an user and a group and has certain access permissions. These permissions are divided in Reading of the file/dir, writing to the file/dir (including deleting of the file/dir) and execution of a file/dir (where execution for a directory means being able to change to that directory (cd)). Each of these permissions can be granted to the user, the group and all others separatly. The permissions are abbriviated with R, W and X, so you can describe the permissions with 9 letters: rwxrwxrwx
Let's say a file is owned by testuser and testgroup. testuser is allowed to R, W and eXecute the file, all members of testgroup are allowed to R and X the file, while all others are only allowed to read the file. This would result in a permission of "rwxr-xr--" (first 3 letters for user, next 3 for group, last for others). That's what you encounter sometimes when viewing a detailed listing of a directory on a Unix system (ls -la).
These permissions again can be abbreviated by using a so called bit mask, masking the R as 4, the W as 2, and the X as 1 and adding them up. Thus in the given example the user would have a permisssion of 4+2+1=7, the group would have 4+1=5, and all others 4, resulting in a bit mask of 754.
Now you know what is meant by 777: The user, all members of the group and all others have the right to read, write (and delete) and execute the file or directory.
Now comes the second part: Usually the webserver on a unix system is running as a certain user, using the rights of that user. Now when the webserver runs your php code that in turn creates a file or directory, this file/dir is owned by the webserver with probably also the group of the webserver. Since you're not the webserver and probably also not in it's group the file permissions of "others" apply to you. If they do not include thr right to Write you won't be able to delete the files/directories created by your php scripts.
Now what to do about it:
Only the webserver's administrator can delete these files now.
In order to be able to delete future files yourself newly created files should be either owned by you or have the permission to write for you - to be on the save side a permission of 777.
However this is not very secure, since every user on that unix system can then read, alter and delete those files.
A better way would be to make newly created files owned by you but only readable for the webserver and others. There is two ways to accomplish that:
1. Ask your admin to create a directory for you, that is owned by you (perm 744) and has the so called sticky bit set. That means that all files created in that directory will inherit it's permissions and ownership.
2. Have your php scripts set the ownership and permissions for newly created files correctly.
I've no idea where this might be done in your scripts, but as you pointed out correctly you can use mkdir for instance with a parameter giving the appropriate permissions. Also you can use chown, chgrp and chmod to change the user, group, and perm of a file (e.g. chown($filename,"testuser")).
BTW: The leading number in a 4 digit bit mask (e.g. 0755) influences the sticky bit. Use "0" and chown,chrgp,chmod instead or ask your admin to set for you or read the tutorials pointed out by DaveRexel.
Good Luck!
Philippe
|
|
|
|
Donna
|
| Posted: 05/20/2002, 4:31 PM |
|
Thank you so much for taking the time to lay that all out for me in such great detail. You made it crystal clear for me! And thanks to everyone else who contributed to the solution!
|
|
|
|
|
