Executing the following from a PHP script called by apache:
$h = fopen(getcwd()."tmp.txt","w");
fprintf($h,"hi");
fclose($h);
generates a file owned by my personal userid with 644 permissions. However, executing the script again results in an error, since Apache/PHP is running as user wwwrun and so doesn't have the permissions to overwrite the file or to chmod it.
The directory that the files are being placed is in my home directory and has 777 permissions. How can I get PHP to either create the file as owned by wwwrun, or create it with 666 permissions, or do something else, to allow it to be overwritten by PHP.
I am ideally looking for a solution which also applies to the situation where the file is created by PHP via an external program called with the exec function; this seems to suffer from the same problem, in that the external program runs as wwwrun, but files created by the external program are owned by my personal userid.
It turns out the directory in question was mounted on a file system that doesn't support linux file permissions.
Related
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.
I am able to write the data to a /tmp directory in Ubuntu but for other directories like writing to /var directory or Desktop, I am unable to write the contents. Is it a permission issue or something else since I am able to edit, modify and read any file from these directory but while writing through PHP code only in /tmp directory I am able to write.
My code is as follows:
$output = "/tmp/image5.png";
//$output = "/home/anand/Desktop/image5.png"
file_put_contents($output, curl_exec($request));
The second $output is not working.
It is the permission issue. Imagine what would happen if everyone could write in everyone's folders. Or delete from them.
You cannot write to your desktop from your PHP script because php script does not have write permission, since it is running from apache user (www-data probably).
You can write to /tmp directory because those files are stored only temporary and everyone can write to that folder.
If you want to write to particular folder (/home/anand/Desktop/ for example), you need to either chown it to www-data (not recommended for your desktop folder), or use chmod 777 /home/anand/Desktop to give write permission to everyone (also not recommended since then other users will be able to write to your Desktop).
I have an Apache server installed which exposes a website written in PHP that I have been working on. One of the functions of the website is to insert new data into a MySQL database. When data is to be inserted the user presses a link which in turn calls a PHP script which contains a line like this
$script_return = exec('python some_script.py);
the python script generates a number of files in the root of the root directory of the site. After creation of these files the script names them after a specific system and moves them to subfolders (via shutil). When I run the script manually everything works fine. When I, however, try to run is from the website the files are created but they are not moved. Both the .php script and the .py script have 777 right and belongs to the www-data group but it still does not work.
Any help would be appreciated.
It sounds like the www-data user may not have the right permissions in your destination folders. If Apache can create the files, it should have rights to move the files.
Why not create the files directly in the location that you want them? That will also give you a more specific error about what's going wrong.
You could also have the python script write a log file somewhere that you can check after.
Once you've got it sorted, I would recommend removing 777 permissions.
We have an PHP XML parsing script that uploads photos to a folder structure like /content/images/2012/05/31/%object_id%/. This parser runs primarily as a DirectAdmin cronjob. We run into many problems getting the folder permissions right to enable the uploading in that directory for both the cronjob as running the parser via the browser.
According to print_r(posix_getpwuid(fileowner($directory))); the owner of the directory is is the same as get_current_user(). Nevertheless I receive: Warning: mkdir() [function.mkdir]: Permission denied when running the script via the browser. It works fine when running it as a cron job.
All folders have chmod 0777 and new folders are created as such;
mkdir($path,0777,true);
Naturally we have the same permission problems with uploading and/or deleting the files themselves.
Is there any way to enable all the file actions running both as a cron job and through the browser?
We are running Linux with PHP Version 5.2.17.
Couple of thinks to note: get_current_user gets the owner of the .php file (i.e. the script) but NOT the name of the user that is running the php script. Invariably these are different as the file will be uploaded by you (a regular user) and php/apache will run as a different user (often called "apache" or "www".) You need the latter of these two. suggested snippet from the php manual to get this is:
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
(http://php.net/manual/en/function.get-current-user.php - see comments)
To solve you current problem, though, my strong suggestion is to run the cron as the same user that the php/apache is running as (check man page on crontab) - the user should be the one in that snippet above, CHOWN the files and directories to that same user (they will currently be root) and to a group that is shared between you and the FTP client. Then make sure the user and group have read+write permissions so you can also edit from ftp. Make sure you change permissions on both directores (775) and files (644) as your script creates them.
Also note that if you mkdir(), then the directory above must also have write permissions for the user (and this might actually be your initial problem, and why only root/cron can write there).
i have this problem with fopen files. Maybe someone has a solution...
When fopen creates a file via the browser, the file is owned by "nobody", if i run the same script via crontab i get permission denied.
When the file is created by crontab, its owned by my cpanel username and then i cant fopen it via the web browser.
So the problem is that each of the methods used is using a different user to own the files created. How can i go around this? I searched how to run crontab as nobody but you have to be root and it seems complicated. I didnt find anything about running my web pages as my cpanel user. My php script has chmod 777 and the folder where the files are also have 777 just be be sure.
Any ideas? Thanks.
I'm not a sysadmin guru, but if you have access to the server you can try this
Create a new group called "webwriters" and add nobody and yourself to that group
"chmod g+s webwriters" on the directory you write files
"chmod 660" each file so that the owner and the group have write privileges
If you don't have access to the server it's trickier, but solvable. Instead of running the script directly by cron, run the script on the web server itself by downloading the web page using "wget" or alternatively a php script calling "file_get_contents" on an URL. This assumes that the server is not locked down too tight...