I keep getting this issue on EC2. I've a cron that is run by root user. Whenever this tries to access files (fopen in read-only or filesize) in a folder that has 777, it fails with an error similar to "Warning: filesize(): stat failed for /var/www/.."
It is becoming increasingly difficult to predict this behaviour. Has anyone faced similar issues? Or any recommended way of setting up users and groups? I'm running it on a default setup. Safe mode is turned off as well.
Added my comment as an answer :
If the cron job is run by root then it's not a permissions issue (root has access to any file). This error is usually issued when the file doesn't exist.
I am not a php guy but here is my best guess. The directory has 777 permission but what about the file's permissions inside that directory. Have you tried running chmod on said directory with -R option?
From man chmod:
-R, --recursive
change files and directories recursively
Related
I know this is a common issue but I haven't been able to single out the problem for my specific use case, so bear with me.
I have a simple PHP script send_id which simply sends an ID number and saves it to a TXT file on my RHEL server running Apache 2.4.6 with PHP 5.4.
The error message: Warning: file_put_contents(/var/www/html/id.txt): failed to open stream: Permission denied in /var/www/html/send_id.php on line 6
'1' written to server
The PHP script itself:
<?php
$id=$_GET['id'];
$stringData = "$id";
$file = file_put_contents('/var/www/html/id.txt', $stringData.PHP_EOL , FILE_APPEND |LOCK_EX);
echo "'$stringData' written to server";
?>
chmodding to 777 didn't do anything. Additionally, I checked to see ownership rights and noticed that the id.txt file is owned by the root user at both user/group level, and PHP is being run at root level.
Anyone have any suggestions? If its any help, this seems to have happened after a yum update
I resolved this issue by simply running chcon -Rt httpd_sys_content_rw_t on the directory where my troubled PHP script lived in.
The chcon command changes the SELinux context for files. However, changes made with the chcon command are not persistent across file-system relabels, or the execution of the restorecon command.
-Rt are to change the type of the directory and its contents, httpd_sys_content_rw_t is to give apache write access
source: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-selinux_contexts_labeling_files
Additional note
ls -alZ *
The -Z switch will work with most utilities to show SELinux security contexts
Try changing the owner of the folder and the file to (chown) to "www-data" or to "www-data:www-data" and see if it changes anything...
Use a relative file path from, Apache's "DOCUMENT ROOT" to reference files in PHP. It's Apache's permissions that matter, and for security reasons it is coded to inhibit access to files outside of DOCUMENT_ROOT.. (yes even though your path leads within it, Apache is blocked as soon as it sees the path starts with "/VAR" ..
Assuming this PHP script is in the same directory as id.txt file , just use
$file = file_put_contents('./id.txt', $str...
Or if the txt file was in a sub-directory
file_put_contents('./sub-dir/id.txt', $str...
Not only is it secure, it's a lot shorter to type too.
I did an installation of laravel, and copied the files to a xampp hosted folder on the same machine. When I try to visit my index.php file however, I'm getting the following error:
Error in exception handler: The stream or file "/Applications/XAMPP/xamppfiles/htdocs/TestManagement/app/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied in /Applications/XAMPP/xamppfiles/htdocs/TestManagement/bootstrap/compiled.php:8969
I'm always a bit hesitant about changing permissions, as I've done some pretty bad chmodding before. Was wondering if there was a rule of thumb or expected behavior for this. Should this be 777 or 755?
The Laravel and Monolog documentation appear to contain no reference to the 'right' permissions. You can make it work with restrictive permissions, but be aware of all of the users that need access:
the web server user
cron user (if you run artisan commands via cron)
anyone who manually runs artisan commands.
They will each need read/write permissions to the log files.
Always use 777 on app/storage folder
I've just uploaded a simple symfony2 app on a production server, and I get this configuration error:
2 MAJOR PROBLEMS
Change the permissions of the "app/cache/" directory so that the web server can write into it.
Change the permissions of the "app/logs/" directory so that the web server can write into it.
editing "app/console", "web/app.php" and "web/app_dev.php" with: umask(0000) doesn't work, and if I right click on that folders with FileZIlla, their permissions are already 777. And so?
thanks...
You need to recursively set the permissions, most likely. I'm guessing FileZilla has that option, if not, ssh into the box, and run (replacing /path/to with the actual path)
sudo chmod 777 -R /path/to/app/cache
sudo chmod 777 -R /path/to/app/logs
Sidenote: setting the permissions to 777 is usually a really bad idea.
umask(0000) doesn't actually increase the permissions available to the script. It just ensures that files & directories created by those scripts are accessible from both the command line and the web server. If you're not using the command line, you probably don't need it at all.
I have written a PHP script for file uploading and for testing I gave my upload directory 777 permissions. The script works fine.
Now I want to remove execute permissions for obvious reasons, but once I do that, I get the following error:
move_uploaded_file([filepath]) [function.move-uploaded-file]: failed to open stream: Permission denied
Just taking the permissions down from 777 to 776 causes this error to appear when I try to upload a file. I don't understand why having execute permissions should have anything to do with this - can someone PLEASE shed some light?
Thank you!
A directory must have execute permission to be accessible in Unix & Linux.
Quoting from here:
On a directory, the execute permission (also called the "search bit")
allows you to access files in the directory and enter it, with the cd
command, for example. However, note that although the execute bit lets
you enter the directory, you're not allowed to list its contents,
unless you also have the read permissions to that directory.
I agree with lserni that the fact that revoking execute permission on the directory for O (the third digit) causes the problem is worrisome as it indicates that the webserver is accessing the directory neither as owner nor as member of the group. You should fix that.
Just taking the permissions down from 777 to 776 causes this error to appear
This shouldn't happen. You ought to be able to run with 770 permissions, i.e., the directory should be owned by the Website user ID, with the group of web server.
This way the owner and the webserver are both able to manipulate the directory and the data. Ideally the Web server serving your website ought to assume the same user ID as the website owner, and that way you can keep the directory mode 700 and have it read-writeable and listable only by you.
If the last digit of the permissions is biting you, it means that the server is running with permissions for "everyone", which may be okay for a development site but isn't too good on a shared site (imagine your passwords being readable by any other website owner in the machine).
However, if you're running on a test machine, the 777 permissions are okay. Directory executable bit does not mean executable (a directory can't be executed anyway) but merely 'listable'. Without that bit, you can create and delete files but you can't know whether they're really there, and move_uploaded_files is objecting to this situation.
There are other solutions (e.g. chrooting each virtualhost in Apache); see also What are best practices for permissions on Apache-writable directories?
for removing the execute permissions you need to execute following commands..
chown -R nobody upload_directory
chmod -R 755 upload_directory
The first command changes the owner of your upload_directory and files under it to 'nobody' which is what php operates under. The second changes the upload_directory and files to only allow user access to writing. -R is for Recursive..
I recently moved my website to a new host and now am experiencing some broken code..
I have an uploading script that is now returning this:
move_uploaded_file() failed to open
stream: Permission denied in *..
I've set the upload directory to 777 which worked fine, but my script is needed to have top level permissions..
(As the script itself sets permission to directories, does lots of copying etc)
Is there a way in apache I can set the PHP script to the owner of all the folders on my server?
Thanks
Also
When looking in phpInfo()
Under
apache2handler
User/Group nobody(99)/99
Is this related?
I wouldn't go that route, just give it permissions to the defined upload_tmp_dir, or define upload_tmp_dir to be a directory you have access to. If it is that directory you have problems with. If the target is the problem, and you've 777'ed it, something fishy is going on.
Do you have ssh access to your new host? The reason I ask is that it's probably not best to use the username/group as nobody, as most other services would use this too. I would change it to something like apache
You can then update httpd.conf, adding in these two lines (reloading the config after):
User apache
Group apache
Then, run chown apache:apache -R dir_name to make apache own it.
well,
When you are trying to set the permission like "0777", you must be running on same authority.
What I mean is.
For example, your script tells to change a folder/file permission to 0777, but the folder or file already has a permission and that is '0755' so you are not authorised to make that change. as the user have only 5 authority.
Either, you need to login to FTP and change the folder permission to 0777 and then you have full control over it or you have to stick with using 0755 or similar.