I have an upload script that uploads a zip file to a directory on my website, it then unzips the file and creates a directory for each file uploaded.
drwxrwxrwx 7 Fabulous admin 238 12 Jan 18:20 .
drwxrwxrwx 39 Fabulous admin 1326 12 Jan 12:28 ..
-rwxr--r--# 1 Fabulous admin 15364 12 Jan 18:21 .DS_Store
drwxr-xr-x 4 nobody admin 136 12 Jan 18:20 2012_06
drwxr-xr-x 4 nobody admin 136 12 Jan 18:20 2012_07
-rwxr--r-- 1 Fabulous admin 2904 31 Oct 16:11 index.php
I have another php script that runs which copies the files in the directories 2012_06 and 2012_07 which where created by the upload script. Every thing is working fine via the browser. However I am trying to automate the process via the command line using the unix command line to call the scripts.
The problem is the script runs if I change ownership of the directories to Fabulous by using the following commands
cd upload
sudo chown -R Fabulous:admin .
However when I do this then my upload script index.php no longer has permission access to upload files to the upload directory unless I change ownership back to nobody.
Error Message
Warning:
rename(/htdocs/data_vis/upload/2012_06/Audit_Log.csv,htdocs/data_vis/data_out/2012_06_Audit_Log.csv): Permission denied in
/htdocs/data_vis/rename_files_in_sdir_with_sdir_name_prefix.php on line 27
Any suggestions/advice or fixes on what I should be doing or the correct way to resolve this via permissioning or any other method are welcome. Thanks in advance.
Either add them both to a group or have the file owned by nobody and group owned by Fabulous you dont need it to be admin, root can access everything anyway
the easiest way is make sure the group stays the same is using sticky bits
if /path/to/dir is owned by the correct group
chmod g+s /path/to/dir
will make it so all new folders under /path/to/dir eg /path/to/dir/1 are owned by the same group as /path/to/dir instead of the users default group
https://superuser.com/questions/102253/how-to-make-files-created-in-a-directory-owned-by-directory-group
Then both your web application should be ok and your cron script without modifing the code
I used the following to change ownership of the files in the directory so the other scripts can use the files.
<?php
// File name and username to use
$file_name= "foo.php";
$path = "/home/sites/php.net/public_html/sandbox/" . $file_name ;
$user_name = "fred";
// Set the user
chown($path, $user_name);
// Check the result
$stat = stat($path);
print_r(posix_getpwuid($stat['uid']));
?>
Related
I am trying a POC running a python script in a back-end implemented in PHP. The web server is Apache in a Docker container.
This is the PHP code:
$command = escapeshellcmd('/usr/local/test/script.py');
$output = shell_exec($command);
echo $output;
When I execute the python script using the back-end we are getting a permission denied error for creating the file.
My python script:
#!/usr/bin/env python
file = open("/tmp/testfile.txt","w+")
file.write("Hello World")
file.close()
This is the error I'm getting:
IOError: [Errno 13] Permission denied: 'testfile.txt'
For the directory im working with the permissions are as follows,
drwxrwsr-x 2 1001 www-data 4096 May 8 05:35 .
drwxrwxr-x 3 1001 1001 4096 May 3 08:49 ..
Any thoughts on this? How do I overcome this problem?
To start is is incredibly bad practice to have relative paths in any scripting environment. Start by rewriting your code to use a full path such as /usr/local/test/script.py and /tmp/testfile.txt. My guess is your script is attempting to write to a different spot than you think it is.
When you know exactly where the files are being written go to the directory and run ls -la and check the permissions on the directory. You want it to be writeable by the same user or group as the web server runs.
Looking at the permissions you have shown you don't have the user able to write to the directory, just everyone and the group. You need to add user write permissions - chmod u+w /tmp will do the job.
I believe the problem is that you are trying to write to an existing file in the /tmp/ directory. Typically /tmp/ will have the sticky permission bit set. That means that only the owner of a file has permission to write or delete it. Group write permissions on files do not matter if the sticky bit is set on the parent directory.
So if this is the contents of your /tmp
$ ls -al /tmp
drwxrwxrwt 5 root root 760 Apr 30 12:00 .
drwxr-xr-x 21 root root 4096 Apr 30 12:00 ..
-rw-rw---- 2 1001 www-data 80 May 8 12:00 testfile.txt
We might assume that users in the group www-data should be able to write to testfile.txt. But that is not the case, since . (the /tmp/ directory itself) has the sticky bit set (the t in the permissions section indicates this).
The reason why the sticky bit is set here is that everyone should be able to write files there, but not have to worry that other users might modify our temporary files.
To avoid permission errors, you can use the standard library tempfile module. This code will create a unique filename such as testfile.JCDxK2.txt, so it doesn't matter if testfile.txt already exists.
#!/usr/bin/env python
import tempfile
with tempfile.NamedTemporaryFile(
mode='w',
prefix='testfile.',
suffix='.txt',
delete=False,
) as file:
file.write("Hello World")
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
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