I have a project I need to generate all sorts of PDF documents for with PHP, so I searched and found TCPDF. All seemd OK until I got to saving files to some folder.
So, I created the needed folder, set 0777 permissions to it, then proceded with generating a file into it. The file was created and all looks good, but the file now belongs to the 'daemon' user, and has 0644 permissions.
I need the generated files to have 0777 permissions. I dont' mind the 'daemon' user as owner, but it would be cool to also know how to set it to the 'root' user.
I searched the official documentation to TCPDF for an answer, but failed to find one, so I came here to ask for help.
So, can anyone help me with some sugestions?
I have solved this problem in my Apache installations on Debian Server by setting the umask environment variable in /etc/apache/envvars.
In my case all I wanted was for the the user and group to have write permissions. I achieved this by setting the umask variable in that file to 007. The mask is applied to the permissions that are inherited by whatever user Apache is running under and so in my case the net result is that all files created by PHP within Apache have 660. I guess in your case you might need 000 (or 0000).
There is absolutely no point setting the execute permission and I would advise against it, because at best it achieves nothing and at worst it might introduce some strange security issue.
This answer contains more info on setting the umask: Setting the umask of the Apache user
The only benefit of this solution over PHP's chmod function is that you can "set it and forget it", the problem being that if you forget to set it then you have a problem.
Related
I've got a new server and when using my php script, I'm able to write files and detect them as being writable even though CHMOD has them as 555 or 755. Is there an apache module or php.ini that is making this possible? Is this a security problem?
What filesystem is your server/volume using?
Some filesystems use different permission schemes, like Access Control Lists in addition to or instead of Unix permissions. For example, you might be using AFS or OpenAFS (Andrew File System) which uses ACL's, in which case you'd have to enter a completely different command to change access. Ask your network administrator; they should be able to answer that. Or you can try running
df -T
to see what that gives you.
You might want to read up on file permissions here:
http://www.zzee.com/solutions/unix-permissions.shtml
That should give you a clue about whats going on.
It doesn't have to be a security hole, file permissions are server side, but if people can upload files they can theoretically, potentially inflict harm by somehow getting their own code running on your server....
It seems i cannot create files. When i set permissions to 777 On the folder i am trying to create a folder in then the script works fine. If the folder is set to 755, it fails. I do not know much about linux, but i am suppose to figure this stuff out. I have spent a couple hours trying stuff. Does anyone know how to make it so that apache has high enough permissions.
I know it is a permissions and apache problem, i just do not know how to fix this. I have edited the httpd.conf file, but i really do not know what i am doing... Any help? (I saved backup.)
Please stop suggesting to use 777. You're making your file writeable by everyone, which pretty much means you lose all security that the permission system was designed for. If you suggest this, think about the consequences it may have on a poorly configured webserver: it would become incredibly easy to "hack" the website, by overwriting the files. So, don't.
Michael: there's a perfectly viable reason why your script can't create the directory, the user running PHP (that might be different from Apache) simply doesn't have sufficient permissions to do so. Instead of changing the permissions, I think you should solve the underlying problem, meaning your files have the wrong owner, or Apache or PHP is running under the wrong user.
Now, it seems like you have your own server installed. You can determine which user is running PHP by running a simple script that calls the 'whoami' program installed in most linuxes:
<?php
echo `whoami`;
If all is right, you should see the username PHP is running under. Depending on your OS, this might be 'www-data', 'nobody', 'http', or any variation. If your website is the only website running, this is easy to change by changing the user Apache runs under. If you have Debian, like I tend to, you can edit the file /etc/apache2/envvars (as root), and change the value for APACHE_RUN_USER. Depending on your OS, this variable might be set in a different configuration file, so if you can't find it in /etc/apache2/envvars, try to search for the variable declaration by using:
$ grep -R "APACHE_RUN_USER=" .
From the directory all apache-config files are in.
If you're not the only one on the server, you might want to consider creating user accounts for every website, and using something like Apache2-MPM-ITK to change the RUN_USER depending on which website is called. Also, make sure that the user the PHP process is running under is the owner of the files, and the directories. You can accomplish that by using chown:
% chown theuser:theuser -R /var/www/website/
If PHP is running with it's own user, and is the owner of the files and directories it needs to write in, the permission 700 would be enough. I tend to use 750 for most files myself though, as I generally have multiple users in that group, and they can have reading permissions. So, you can change the permissions:
% chmod 0750 -R /var/www/website/
That should be it. If you having issues, let us know, and please don't ever take up any advice that essentially tells you: if security is bothering you, remove the security.
I have a similar problem but in my case I have SELinux running and it failed even with 0777 permission. Turns out I need to explicitly allow httpd to have write access on the directory using:
chcon -R -t httpd_sys_rw_content_t <PARENT_OF_MKDIR_TARGET>
SELinux Troubleshooter may have more details.
On ubuntu you edit /etc/apache2/envvars as Berry suggested.
When you change the Apache user, beware of unintended consequences. One of them is the PHP sessions that may be stored in /var/lib/php5. You may need to change the ownership of that folder too.
Why would file_put_contents refuse to work for the following code?
$f = file_put_contents("files/r.js", "Some text here");
if ($f) print 1;
else print 0;
It could be a permission problem
Is the directory /files chmoded to 777? sometimes php won't allow you to access directories if they don't have enough permission. I don't know about blank errors though.
Try to see if it has enough permissions, if not, then set it to 777 and try it.
Are you using the full path on the filesystem or are you trying to use the URI? I think this PHP function expects you to give the path as the file is found on the filesystem.
Relative paths should be okay though.
You may need to make sure the file exists and that it's permissions are set to 777. Sometimes I've found that it's not enough to just have the directory permissions set to 777 but the file must also already exist.
It is because of SELINUX.
You can mark the folder as of type httpd_sys_rw_content_t with this command to enable writing to this folder.
semanage fcontext -a -t httpd_sys_rw_content_t '/files(/.*)?'; restorecon -RF '/files/'
We've experienced this, requiring a workaround (regardless of method, permissions and anything else mentioned here). When all other fixes failed, we have found it can be linked to restrictions created by SELinux.
If you’re using windows the following solution worked perfectly for me on Windows 10 running php 5.5.38
If you’re having this problem on Windows/IIS try the following:
Go to the Folder that you are trying to write to and right click it, then select properties.
Select the Security Tab
Click Edit
Click Add
Click Advanced
Click Find Now
From the list of User select IUSR and click OK
Click OK again.
The IUSR will be displayed in the top box labelled 'Group of User Names'
Select IUSR and grant necessary permissions in the 'Permissions for BATCH' list view.
Click Apply and then you are done.
The steps may be slightly different for different versions of windows. This also applies to ASP.NET though I think the users you add are the network users (NETWORK AND OR NETWORK SERVICE users) as well as the IUSR.
PHP creates files with apache:apache ownership which seems to be causing issues with other php scripts accessing the file.
How can I allow php to create files with the same ownership as the files that created them?
I've read elsewhere that having safe_mode turned on can affect this but I've turned it off and reuploaded the files and i still get the same issue.
I'm sure this will be a simple question for someone more familiar with apache but I've failed to find the solution by searching around.
Thanks
If ownership matters and multiple users / projects are on the same server, you might want to look into SuExec in Apache: PHP files will then be run by the user indicated in the settings, so default ownership of files is automatically taken care of. It saves a lot of chown/chmod'ing, and the processes run by the user are more easily restricted.
Otherwise, I normally create a group with both the owner & apache, and set the default umask to 007.
If you are using a Windows OS you can start Apache as a service and allow apache to use your own account's permissions when starting.
Try using fileowner ( http://www.php.net/manual/en/function.fileowner.php ) to get the id of the owner of the current script, posix-getpwuid to get the username for that id ( http://www.php.net/manual/en/function.posix-getpwuid.php ) and chown ( http://php.net/manual/en/function.chown.php ) to set the user for the files.
Why go through all the programatic hassle to change the owner? apache.apache is a very insecure owner anyway. Why not just chmod 0777 the file providing read, write, and execute to all owners. This will eliminate the issue.
If you are still having troubles, then you may need to check if open_basedir is on. If that is the case, it is not file ownership or permissions, but location. This basically means you need to put the file in a location that apache/php already has included in their path.
A.M. mentioned chown() above, please be aware that generally chown() can only be used by root and your webserver running account is highly unlikely to be root, that's a very bad idea.
It is possible to setup sudo to allow chown by other users in specific areas and only to specific users. Just have to create a suitable entry in /etc/sudoers, usually by using the visudo program. If you do not have root access yourself, then your hosting provider will have to do this for you, if they will.
For more information: http://www.sudo.ws/sudo/sudo.html
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.