Page 3 of 4
Posted: Sat May 22, 2004 10:38 am
by mjseaden
They are:
Owner Read/Write/Execute
Public Read/Write/Execute
Cheers
Mark
Posted: Sat May 22, 2004 10:41 am
by launchcode
Try a test and set them to world read/write and then upload a new file and try to unlink it again.
Posted: Sat May 22, 2004 10:49 am
by mjseaden
Hi Launchcode
I've tried uploading again. I set the 'upload' directory to CHMOD 1777 (the highest it can be as far as I'm aware), and also to 'sticky'. The upload process creates a directory in upload, and then proceeds to upload files to that directory.
I just ammended my PHP upload script with
Code: Select all
chown( 'upload_path_file', 'rootusername' );
However, even in the same script, it gives the error
Code: Select all
Warning: chown failed: Operation not permitted in /XXX/public_html/admin on line 2397
Posted: Sat May 22, 2004 10:50 am
by mjseaden
This confuses me, because apparently although move_uploaded_files and the post-data method can upload to my server with that username and group, the same script cannot change the ownership.
An apparent conundrum.
Posted: Sat May 22, 2004 11:32 am
by launchcode
That isn't totally unexpected - it's just saying it cannot assign the files to your user account (which is unfortunately correct, it doesn't have that kind of permission).
I'm more interested in if you can delete the files from the same script as you upload them with?
"upload process creates a directory in upload" - which will also need 777 for this test.
Posted: Sat May 22, 2004 12:18 pm
by McGruff
launchcode wrote:Very rarely have I seen a PHP "own" anything, unless that server has specifically created a php user and set scripts to run as it - if they haven't, they will be run as the default Apache user account which has the same lack of privs as "nobody". If you just think about the security implications of allowing one single "php" user to read/write anywhere on a shared server - well, you could cause havoc.
I do all the coding on a not for profit site where this is indeed the case. And you're right about the risks: I once wrote a file browsing script with an "up a level" button. You can jump right out of root to view a list of thousands of other sites on the same server...
Posted: Sat May 22, 2004 12:20 pm
by launchcode
McGruff - that doesn't surprise me at all - there are loads of hosts out there who either incorrectly configure their servers, or don't tell their customers how to lock down their home directories. Ah well, such is life

Posted: Sun May 23, 2004 8:10 am
by mjseaden
Hi
I still seem to be having problems. It appears now that I am able to delete files from the server via PHP, however the script works by first copying the files (photos) from the user's computer to the server, before resizing them physically using GD, resaving them, then moving them to another directory. This directory is created via the script, inside a directory that I initially created using FTP. However, when I try to use the usual mkdir() I am getting another permissions error!
Is this because I am trying to create a directory inside one created under my username and group, and PHP is trying to create a directory under the ownership 'apache' and group 'apache'? A ream of other errors are being produced as a result of this.
I hope that makes sense
Many thanks
Mark
Posted: Sun May 23, 2004 8:17 am
by launchcode
Permissions cascade, if a top level directory is set to read only for example, you won't be able to write into a sub-dir of it. Open it all up.
Posted: Sun May 23, 2004 8:20 am
by mjseaden
The problem is, I then have to set permissions to 'public write' on the photo directory, which of course leaves way for potential problems.
Is there any way I can configure PHP to write/read under my own username and group? This would effectively solve all the problems.
Posted: Sun May 23, 2004 8:24 am
by launchcode
There may be other ways, but the host I use (Pair Networks) provides this facility via a wrapped version of PHP. Another way would be to have a locally compiled version of the CGI version of PHP which would then run under your user account.
Depends how much control you have over the server I guess.
Posted: Sun May 23, 2004 9:10 am
by McGruff
mjseaden wrote:Hi
...the script works by first copying the files (photos) from the user's computer to the server, before resizing them physically using GD, resaving them, then moving them to another directory. This directory is created via the script, inside a directory that I initially created using FTP. However, when I try to use the usual mkdir() I am getting another permissions error!
Is this because I am trying to create a directory inside one created under my username and group, and PHP is trying to create a directory under the ownership 'apache' and group 'apache'?
Mark
Exactly. Your ftp program is operating under a different UID to php - that's normal.
Can you create the second directory (where you move the images to) with php rather than ftp? You might need to CHMOD 777 (with your ftp program) to allow php to mkdir inside a dir owned by another UID but, once it's there, you can CHMOD back to 755. A php-owned file or dir can live happily inside a dir with another owner/group.
Posted: Sun May 23, 2004 9:12 am
by mjseaden
Hi McGruff,
I could do this, but I wouldn't really be able to manually change permissions each time a file is uploaded. I am not the only one uploading files, rather remote users with a username and password given by myself will also be able to, therefore it needs to be fully automated otherwise it creates unnecessary work.
Funnily enough, I didn't have any problems like this when I was using a Windows server with the same code a couple of weeks back.
Posted: Sun May 23, 2004 9:41 am
by launchcode
That's because Windows doesn't have the first inkling of security and you could over-write anything with PHP on a Windows box!

Posted: Sun May 23, 2004 10:28 am
by mjseaden
I think the only solution is to configure PHP to carry out file transactions under my own username and group (i.e. same as FTP etc.), right?