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>
Related
I'm trying to work out why I need x permissions for others on a directory to read the stats of the files within it.
this is my folder:
4 drw-r--r-x 2 root root 4.0k Dec 7 17:40 file_host
When the permissions are set so x is assigned to others I can read the files filemtime etc without issue. If I remove the x then I get:
Warning: filemtime(): Stat failed for /file_host/file1234.zip (errno=13 - Permission denied)
The permission on the files in the directory are:
9684 -rw-r--r-- 1 root root 9.4M Dec 7 17:40 file1234.zip
As soon as I add x to the folder it all works. The web user isn't root and doesn't have any root privileges.
Why do you need x to execute the file to read it's values ?
Any way around this ?
Thanks
The execute x bit is what allows a user to descend into a directory. The way your folder is owned, you require execute bit on the other portion of the permissions to allow the www-data / apache user to descend into the directory. If you run chown root:www-data and then remove the x bit on the other portion you will notice this will continue to work without giving all other users on the OS access to the directory.
I'm implementing a file upload in symfony2. My File entity is owned by a User, and represents the uploaded file. The uploaded files should not be accessible for anyone except admins and the owner. For addressing this (apart from securing the controller), I save them in a directory which is not under /web/. I called this directory /private_files/ (and is located at the root of the project).
To allow the web server to write to that directory I ran this (I'm on Mac OS X Mavericks):
$ sudo chmod +a "`whoami` allow delete,write,append,file_inherit,directory_inherit" private_files/
$ sudo chmod +a "www allow delete,write,append,file_inherit,directory_inherit" private_files/
The uploading works fine. However when trying to delete the files through the controller, with
unlink($path)
I get the error "Warning: unlink(path/to/file): Permission denied".
When listing the files on the terminal with ls -al, I get
drwxr-xr-x+ 3 myuser staff 204 Mar 23 11:59 .
drwxr-xr-x 24 myuser staff 816 Mar 21 19:51 ..
-rw-r--r-- 1 _www wheel 7395585 Mar 23 11:59 uploaded_file_1
where I notice that the uploaded files lack the executable permission and the "+" which represents the ACLs.
What's the correct approach to allow these files to be deleted with the unlink method? Should the files inherit the ACLs (and if so, how)? Or should a chmod be applied on the directory? Thanks a lot.
I think it is because your folder is not owned by apache user which handle php.
because you created the folder /private_files/ with another user not with apache user, for the app/cache is created programically so he own it and can create/delete. i will update it as answer
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.
I run a third party PHP application on my local AMP stack on my Mac. I recently bought a new Mac Mini with Lion, and am trying to set it up. My previous computer was a MB air with MAMP. Now I'm using the built-in apache/php and a homebrew installed MySQL.
Here's my problem: I have a directory with symbolic links. These symlinks are to directories, and the PHP application is checking these with is_dir().
On my Lion AMP setup, this is_dir() is failing. The same setup on my Snow Leopard MAMP is_dir() works fine with my symlinks.
Here's where it gets more curious. If I do php -a (php interactive command line mode), and do is_dir() on the very same directories, it returns true. It only returns false in the context of an apache request. This makes me think it has something to do with the apache user (which is _www) not being able to access the symlinks. Troubleshooting this falls outside of my expertise.
Other notes:
Yes, I have FollowSymLinks turned on in my apache config, and in
fact, the directory where the symlinks in question reside is a
symlink itself. Apache has no problem with it. Until PHP is_dir() is
used.
No, I cannot edit the PHP application and just fall back on is_link()
and readlink().
This exact same setup worked on my Snow Leopard/MAMP setup.
Any ideas?
Ah saw your comment on changing them to 777 but still wondering why it's not working.
My solution below might not help you.
EDIT:
If you have access to /etc/apache2/httpd.conf, edit it via sudo vi /etc/apache2/httpd.conf.
Then change these 1 of these lines or both of them
User _www
Group _www
Here is an example of my directory listing.
ace:remote-app ace (git::master)$ ls -al
total 72
drwxr-xr-x 24 ace staff 816 7 Aug 00:24 .
drwxr-xr-x 11 ace staff 374 4 Aug 13:46 ..
drwxr-xr-x 3 ace staff 102 12 Jul 17:06 .bundle
drwxr-xr-x 14 ace staff 476 7 Aug 02:29 .git
-rw-r--r-- 1 ace staff 100 1 Aug 19:20 .gitignore
-rw-r--r-- 1 ace staff 9 1 Aug 19:20 .rspec
drwxrwxr-x 10 ace staff 340 14 Jul 15:58 public
Now my public directory has 775 permissions, meaning owner and group have full permissions while other users can only read and execute.
It depends if you want apache user to become ace from the default _www or the apache group to become staff from the default _www.
Once you've decided on which to change, restart apache.
/usr/sbin/apachectl graceful
And your page should now have access to the directories / files.
One thing to note is that you have to change ownership for files that have been already been written by your webpage as those have _www:_www ownership and you won't have access to them after the restart.
You can change their new ownership through this, -R is to make it recursive.
sudo chown -R newapacheuser:newapachegroup <path>
Did you check permissions/owner?
From the PHP manual: Note: The results of this function are cached.
I had a similar issue. I created the following link:
cd /home/mike/uploads
ln -s ./data /sites/www.test.com/docroot/data
Then I created a test.php file in /sites/www.test.com/docroot that just did the following:
$dir = "/sites/www.test.com/docroot/data";
"is_dir\t\t" .is_dir($dir) ."\n";
When I ran test.php from the command line, it would show up as is_dir was True, but when I loaded test.php from a browser through apache, it was False.
I went to /sites/www.test.com/docroot/data and did a
chmod -R 755 .
That didn't change anything. Then I realized, the parent to the actual symlinked dir needed proper permissions set (/home/mike/uploads). I did a chmod on that dir, and everything worked!
Check open_basedir directive in php config. That path should also be included.
In linux, you can list multiple folders by separating them with a colon.
https://www.php.net/manual/en/ini.core.php#ini.open-basedir
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