When uploading images through PHP the resulting file is being created with permissions that don't allow Apache to read the files on later requests. Example permissions for an uploaded file look like this:
--w-rw----+ 1 www-data www-data 76551 Jan 29 19:52 original.jpeg
The permission on the containing folder look like this:
drwxr-xr-x+ 41 www-data www-data 4096 Jan 29 19:52 media
Apache is running as www-data This issue only happens in staging (of course). In my dev environment files upload without issue so it's not likely to be a code issue. I am employing Ubuntu's ACL and I suspect this may have something to do with it.
The result of getfacl on the upload directory:
# file: web/media
# owner: www-data
# group: www-data
user::rwx
user:ubuntu:rwx #effective:r-x
group::r--
mask::r-x
other::r-x
default:user::-wx
default:user:www-data:rwx
default:user:ubuntu:rwx
default:group::r--
default:mask::rwx
default:other::--x
The result of getfacl on the file itself:
# file: web/media/original.jpeg
# owner: www-data
# group: www-data
user::-w-
user:www-data:rwx #effective:rw-
user:ubuntu:rwx #effective:rw-
group::r--
mask::rw-
other::---
Any ideas?
I figured it out. As suspected it was an ACL issue. The default:user::-wx line of the ACL on the upload directory was dictating that new files should be created with -wx as the user permission. Running sudo setfacl -d -m u::rwx <upload dir> fixed this.
What's your umask?
<?php
umask(0022); //unset the write bits, should yield rw-r-r-
//Then your file magic
file_put_contents($filename, $content);
Related
I have a PHP script on my web server that uses a private key so my directory structure looks like this
-- script.php
-- private-key
-- lib/
What permissions should I set my private-key file too so that it can be used by script.php but not by anyone else. I've tried setting the permission as 664, is that correct?
Setting your permissions as 664 means that anyone can read the file. For a private key file, you should at least remove last 4 (660). I would probably make the owner the user that is running script.php and then set the permissions to 400.
If your file permissions look something like this:
user#host:~$ ls -l
-rwxr-xr-x 3 apache apache 4096 Jan 6 15:32 script.php
-rwxr-xr-x 2 apache apache 4096 Dec 13 11:25 private-key
drwxr-xr-x 14 apache apache 4096 Dec 13 15:03 lib/
Then something like this would be more secure:
chown apache:apache private-key
chmod 400 private-key
This will make it so the only user that can read the file is the apache user.
To make life a little easier for you, you might want to add a group and fiddle with the group permissions so that your user can edit the file as well.
I'm having trouble handling the uploaded files on my web server.
First the file is uploaded to the temp server by user "daemon" then I copy the file to www/myapp/files folder by the "www-data" user. Everything works fine, I can read and write to the file, but when I try to delete the file I get an error. Because I'm trying to delete the file as www-data user (php script), but the owner of the file is daemon user.
My question is how can I fix this?
I'm not looking for any chmod or chown solutions, I prefer the solution to be through Apache or some other configuration files.
EDIT:
As requested file permissions:
-rw-r--r-- 1 daemon daemon 41638 Jan 19 08:59 FILE
The parent folder has 0777 permissions
You can add both users to one group like this:
usermod -a -G groupName userName
And then set up r\w permissions for that group
Avoid assumptions
Everything works fine, I can read and write to the file
This indicates that the file permissions themselves, and ownership, permit current usage. If as you say apache is running as www-data, it directly contradicts this:
As requested file permissions: -rw-r--r-- 1 daemon daemon 41638 Jan 19 08:59 FILE
Which would mean the file is not writable to www-data.
Because I'm trying to delete the file as www-data user (php script), but the owner of the file is daemon user.
The above statement is not true - ownership of a file does not affect who can delete it.
I'm not looking for any chmod or chown solutions, I prefer the solution to be through Apache or some other configuration files.
How about not ruling out solutions until you have a choice =)?
Deleting a file uses directory permissions, not file permissions
This is easily verifiable:
-> pwd
/tmp/so
-> whoami
www-data
-> ls -la
total 8
dr-xr-xr-x 2 www-data www-data 4096 Feb 18 14:34 .
drwxrwxrwt 8 root root 4096 Feb 18 14:36 ..
-rw-rw-r-- 1 www-data www-data 0 Feb 18 14:34 a-file
-> rm a-file
rm: cannot remove `a-file': Permission denied
note there is no write permissions to the folder /tmp/so - it's the only permission that matters. Here's another existing answer as a supportive reference.
So given that, the only solution is to ensure that the user attempting to delete a-file has write permission to the containing folder, which means for example:
# assuming daemon is the owner
chmod 7x7 www/myapp/files
^ www-data is not the owner or in the group daemon - so world perms apply
Or
chown www-data:www-data www/myapp/files
chmod 7x7 www/myapp/files
^ daemon needs write permission to the folder too
Or
chown www-data:sharedgroup www/myapp/files
chmod 77x www/myapp/files
^ daemon now reads the group perm, www-data is the owner
(With the upload process running as daemon:sharedgroup)
The above are one-time-only commands that need running; after which there is no need to modify the permissions for any file or folder to permit both www-data and daemon to manipulate files in www/myapp/files.
Under linux, using php 5.3
If I use mkdir in a php script to create a folder, then I have full access on this folder to add files or create folder inside it.
If I then login on the server via ssh, create a second folder, chown(recursively or not) to the exact same user:group as the one created by the php mkdir(), and chmod it to the the same exact permissions as the first folder then trying to access this folder to add a file or create a new folder inside it will throw a permission denied.
Trying to chmod 777 does not work either. I cannot for the life of me figure out the difference between the two :
drwxr-xr-x. 2 amadeous psacln 4096 6 oct. 02:38 test
drwxr-xr-x. 2 amadeous psacln 4096 6 oct. 02:39 testtest
Any idea appreciated.
EDIT AFTER COMMENTS
The apache user is running with the user amadeous in the group psacln.
mkdir() does create the new directory with this user and group
A exec("whoami") returns amadeous as well.
But still no go.
EDIT 2 AFTER COMMENTS ABOUT SELINUX BY GUIDO
ls -Z does give different results although I don't know what to make of it :
drwxr-xr-x. amateous psacln system_u:object_r:httpd_sys_rw_content_t:s0 test
drwxr-xr-x. amateous psacln unconfined_u:object_r:user_tmp_t:s0 testtest
How do I go about fixing this ?
Thanks
The right labeling for files and directories accessible from the httpd apache processes is
httpd_sys_content_t; while the files generated have user_tmp_t:
ls -Z
drwxr-xr-x. amateous psacln system_u:object_r:httpd_sys_rw_content_t:s0 test
drwxr-xr-x. amateous psacln unconfined_u:object_r:user_tmp_t:s0 testtest
To fix the labeling, run (more info):
chcon -t httpd_sys_content_t <directory>
Is there a way to set php running under apache to create folders with the folder owned by the owner of the program that creates it instead of being owned by apache?
Using word press it creates new folders to upload into but these are owned by apache.apache and not by the site that they are running in. This also happens using ostickets. For now we have to SSH into the server and chmod the folder, but it would seem there would be a setting somewhere to override the ownership outside of any program that does it.
Safe_mode is turn on on your server. The function mkdir() creates folder with owner ("apache", "none", ..) that different of the current script owner. And scripts couldn't upload (move, copy) files into that folder with another owner (that is not like current script owner).
Disable safe_mode and that would be work.
See http://php.net/manual/en/features.safe-mode.php for details.
P.S. With enable safe_mode you can't use chmod() function in php.
Another way is to put the apache user and the "customer users" in a new group. Additional the directory should use the sticky bit SGID so each new file got the group assignment to this new group. This way the webserver and the "customer users" can work with the files without any problems
[17:57] progman#proglap /tmp/test $ ls -al /tmp/test
total 9
drwxrwsr-x 2 root users 48 Apr 1 17:55 .
drwxrwxrwt 36 root root 9264 Apr 1 17:53 ..
As you see the directory got the stick bit SGID and the owner is the "users" group in which I (progman) am. No if another user adds a file the group automatically get set to this group
[17:55] proglap ~ # touch /tmp/test/x
This is executed from root. Now we get:
[17:57] progman#proglap /tmp/test $ ls -la /tmp/test
total 9
drwxrwsr-x 2 root users 72 Apr 1 17:59 .
drwxrwxrwt 36 root root 9264 Apr 1 17:53 ..
-rw-r--r-- 1 root users 0 Apr 1 17:59 x
As you see the added file is from root, but the group is set to users and this way I can remove it
[18:00] progman#proglap /tmp/test $ rm x
rm: remove write-protected regular empty file `x'? y
[18:01] progman#proglap /tmp/test $ ls -la /tmp/test
total 9
drwxrwsr-x 2 root users 48 Apr 1 18:01 .
drwxrwxrwt 36 root root 9264 Apr 1 17:53 ..
Keep in mind that you still need to change the chmod if you want to edit the file as rw-r--r-- is just group read access. But changing the chmod, maybe even working with umask, is better than dealing with root-access and using chown.
Not directly, no. You can't "give away" ownership of a file to another user, unless you're root. You could investigate using the "AssignUserID" apache directive to force that particular vhost to run as a particular user/group. With that Apache/PHP would create any files with the appropriate ownership
Check out PHP chown() function
I am trying to read and post back to the browser a file uploaded with the zend framework mechanism.
The file has been uploaded correctly to the desired location and as I have checked by
su www-data
and after an ls and a cat, the web user can read it and modify it properly.
the problem is that inside a controller when I try to:
if(!file_exists($fileName)) {
die("File ($fileName) wasnt set or it didnt exist");
}
I am always getting to die(...), although the $fileName is a string and when I display it's location I can always (as stated before) read it from the command line.
ls output:
$ ls -lah
total 112K
drwxr-xr-x 2 www-data www-data 4.0K 2009-10-07 18:21 .
drwxr-xr-x 3 www-data www-data 4.0K 2009-10-07 13:57 ..
-rw-r--r-- 1 www-data www-data 70K 2009-10-07 17:33 Eclipse_Icon_by_TZR_observer.png
-rw-r--r-- 1 www-data www-data 27K 2009-10-07 18:24 eclipse_logo2.png
Stat output:
stat() [function.stat]: stat failed for .../eclipse_logo2.png
I saw a very similar question to the "try for 30 days" site, so it is not something that has happened to me...
Any ideas?
You have to chmod the newly created file because the file owner created from PHP side will be Apache (group: www-data, httpd, www, or something similar). So next time PHP cannot access the file because www-data owns it and it has wrong permissions.
Here's how you create new files so that you can access them later.
<?php
$path = '/path/to/new/file';
touch($path)
chmod($path, 0777);
// TRY to change group, this usually fails
#chgrp($path, filegroup(__FILE__));
// TRY to change owner, this usually fails
#chown($path, fileowner(__FILE__));