What permissions do I need to set up on a directory in order to make it writable by php?
By "writable", I mean copying and creation of new files within that directory automatically by php itself.
I'm testing this on a free host, and the default permissions are 755.
When I try executing a php script, that attempts to create another subfolder of that directory, and copy certain files in it, and it fails.
If I set it up to 777, it works fine, but I assume that doesn't work on all Apache versions because of security reasons?
Also, when creating new files, does php act as the "owner"?
Whatever process that runs the PHP interpreter should should have a user account associated with it. Only that user needs write permission in the directory. So to answer your last question, it's usually www-data or apache that is the owner of that file.
Permission of 777 will work because it allows everyone to read, write and execute that directory but depending on your application this might be a security hole.
Related
I am using Jasperreports for generating the reports. When I am generating the new reports it will be own by root with permission of 644. So other users dont have permission to view this report.I want to change the ownership of the file or change the permission.So everyone can view or download the reports.
I tried below php functions
chmod($item, 0777);
chown($path, 'www-data');
It gives
error: dont have permission to do this
. Because its own by root and current user is www-data.
Anyone please help me,
Actually, based on what you're saying, all users have permissions to view that file. 644 means owner can read and write, and group and others can only read. If your script is getting an error reading that file, it might be because of the permissions of the directories in is path, but not the file itself.
If you could change the owner or permissions of a file owned by root like that, it would subvert the whole concept of unix file permissions. Think about it.
You can always change the user running these reports though, or add logic on the report generation side to move or change the permissions on the file as the user who owns it.
As an aside, chmod 777 is an ugly kludge used only by those who have little knowledge of unix permissions . Professionals don't do it. You should bump your understanding of unix file permissions to the next level:
https://www.tutorialspoint.com/unix/unix-file-permission.htm looks promising.
According to the manual, the owner and the supersuer have the right to do this.
And you only chage the file mod or owner, will not do. You have also to change the path.
chown
Attempts to change the owner of the file filename to user user. Only
the superuser may change the owner of a file.
Note: This function will not work on remote files as the file to be examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or directories being operated upon have the same UID (owner) as the
script that is being executed.
chmod
Attempts to change the mode of the specified file to that given in
mode. Note: The current user is the user under which PHP runs. It is
probably not the same user you use for normal shell or FTP access. The
mode can be changed only by user who owns the file on most systems.
Note: This function will not work on remote files as the file to be
examined must be accessible via the server's filesystem.
Note: When safe mode is enabled, PHP checks whether the files or
directories you are about to operate on have the same UID (owner) as
the script that is being executed. In addition, you cannot set the
SUID, SGID and sticky bits.
I have an image upload script. I ran into some trouble with permission errors so for the last little while the upload directory has had permissions 0777. Dangerous, I know.
For some reason, it was the only permission that would allow the files to upload. I have now realised that the reason a safer permission didn't work was because of the owner of the directory.
I've been creating my upload directories using FTP. I thought this would be okay. But from what I understand FTP and HTTP aren't in the same group?
I've started creating the directories using PHPs mkdir() allows me to set a safer permission that works with my script.
But before I possibly get into another bad habit. Can someone please confirm that this is the correct way to do it? Is there a better way?
The owner of the directory should be the user which runs your PHP script - on Ubuntu this would be www-data. Shortly, creating folders with PHP mkdir() is okay. Then you should set permissions. 0700 is the most secure but if other user needs to read from or write to this directory, you should add this user to the main group of user which runs your PHP script and set permissions to 0750 or 0770 respectively. On Ubuntu this group is also www-data.
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 am trying to set up automated .htaccess updating. This clearly needs to be as secure as possible, however right now the best I can do file permission-wise is 666.
What can I do to setup either my server or php code so that my script's fwrite() command will work with 644 or better? For instance is there a way to set my script(s) to run as owner?
EDIT:
I realized I actually just had a permissions issue, you should be able to use fwrite no problem with 644 permissions. See my answer below.
The apache process should always run as apache:apache - if you must enable write permissions in executable (i.e. DocumentRoot) directories, create a group, add apache and set group write permissions (so 664).
It's best to have .htaccess updated by a cron script reading config data from a database, as giving apache write permissions to executable directories is frowned upon in case a vulnerability in your code allows a malicious user to write new files to those directories.
You can't change the process's owner. If you're on a shared server, see if they have suPHP as an option.
These suggestions were great, however I ultimately realized that the answer to my question is YES - and you shouldn't have to do anything at all... as long as the Owner user of the file/directory you are trying to write to is the same user the script is running as. My mistake was that I accidentally had my file ownership out of whack therefore needed higher permissions 666 and 777 in order to write to my files. Which makes sense because Wordpress can write to .htaccess with standard permissions.
Now I have things setup where a file running as user1 is writing to a file owned by user1:user1, and no problems whatsoever. Directories set to 755, .htaccess file set to 644.
How should I handle image uploading using PHP?
How should I handle the chmod settings?
Example;
I have a dir called /image/ where i want to upload all my images.
Should I set this dir to chmod 777 and leave it like that? Or should i change chmod on that folder via PHP each time I need to upload a image. Is this correct, or should I be doing something else?
As thephpdeveloper mentioned, setting chmod once is enough. All subsequent writes into that directory will not change the directory permissions unless you explicitly chmod it to another permissions somewhere else.
The recommended permissions for directories on a *nix server is 755.
Setting permissions to 777 is not recommended. As mentioned by wic, it gives full permissions to everyone that have access to your server. Which makes it vulnerable if you are on shared hosting or sharing the server with other users.
Also to note is how PHP is run on your server. In fact, if you are running PHP as cgi, example suphp, permissions of 777 for directories are not allowed. Having 777 permissions on the directories your scripts reside in will not run and will instead cause a "500 internal server error" when attempting to execute them.
I recomend chmoding to 755
Only the user running the web server dameon needs permissions to the directory for writing. And you certainly don't want execute permissions on a directory users are uploading to.
Usually, folder settings are set once and that's it. It's rather pointless to keep setting the folder permissions to 777 via PHP, when you have already set it to 777.
No, you dont have to change the permissions on the directory each time. Once set, they are set so to speak.
Using 777 is overkill since it gives full permissions to everyone. Remove the 'x' bit and let apache (or whoever) own the directory. This makes it impossible to list files.