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).
Related
I'm codding a php script, using Instagram Private PHP Api.
It's work fine via SSH under "root" user, but when I try to run it via browser or cron, I getting error: Warning: chmod(): Operation not permitted in .....
I guess that something wrong with permissions, but I am not really good in server administration and can't understand what I can do =(
Please help, how I can fix this problem?
Because Apache (or the web server you're using) executes PHP using different Linux user (usually www-data), which obviously have different permission than the user account you used in access via SSH.
To tackle the problem, you first have to know the folder / file you're going to chmod() belongs to who. If it belongs to root, then it's not suggested to chmod via any scripts that is accessible by public due to security concerns.
If it belongs to your user name, say foo, you can change the ownership of the folder / file you're going to chmod() to be accessible by www-data group using chown() in SSH console, then you chmod() command can be executed without problem.
The user that PHP runs as must have permissions to chmod the given file or directory. If you're running this script via CRON, you get to set the user that PHP runs as right in the CRON job. If you're visiting the script in a browser, PHP is likely running as php or php-fpm or the web server user.
Simply ensure that the given file or folder is owned by the user that PHP runs as.
Note: It is not recommended that you run this script as root in CRON.
If you are editing /etc/crontab, make sure the user parameter (the one after week) is root.
If you are editing crontab via crontab -e, add user parameter crontab -eu root.
I have a code on PHP that was working in a server but we migrate that code to another server and now that code is not working, specifically we want to run an .exe file using PHP with the instruction exec
I debug the script and it looks be working properly and the IUSR user and IIS_IUSR have the correct permissions and actually the exe file is running, but, when it run it need generate some files that is the part that cause the issues, the program are trying to create files on the AppPool directory for example like this:
C:\MyPath\somewebsite.com\8áª\MyProgram\
Where C:\MyPath\somewebsite.com\ is the AppPool root directory and MyProgram\ is the directory that the app is creating
Where \8᪠is generated randomly and changes all the time that we try to run the program, debugging with Process Monitor I can get an error: PATH NOT FOUND and/or NAME INVALID, on the previous server we modify the user on the IIS to run the script (that was on IIS 6 now we are on IIS 8.5) and that files was created on the home directory of the user AND without the random directory, for example:
C:\Users\MyUser\MyProgram\
where MyUser is the user that we assigned, but on that new server we get the files on the AppPool directory no matter if we change the user
I think that we can solve that if we was able to define a path for the IUSR user and set it as "home" path but I cannot found where to modify the IUSR user, I know that is a build-in user that IIS create but I'm not sure if I can edit that settings for that user.
I already mention that we used IIS but just as an extra data, we are running that over Windows Server 2012 R2
Any suggestion?
You topic / question is:
IIS does not allow run .exe file using excec command on PHP
which is the correct behavior! You don't want to run .exe files through PHP, really. You have to give the IUSR execute permissions on cmd.exe first, meany you might as well give all your virtual users administrator permissions.
lot of time after but, PHP side was ok, the problem was on the .exe file, the exe file create some files that was used for the same exe program, but it uses relative paths so when the process run makes that did not found the files generated and this caused the errors
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.
This question is related to another question I wrote:
Trouble using DOTNET from PHP.
Where I was using the DOTNET() function in PHP to call a DLL I had written.
I was able to get it working fine by running php.exe example.php from the command line (with the DLL's still in the PHP folder).
I moved the php file to an IIS 7 webserver folder on the same machine (leaving the DLLs in the same php folder), but I keep getting a 500 internal service error.
I've checked the server logs (in c:\inetput\logs\ and in c:\windows\temp\php53errors) but there doesn't seem to be any relevant information about what caused the error. I even tried to change the php.ini settings to get more error feedback, but that doesn't seem to help.
I can only guess that the issue may be related to:
that php file not having the proper permissions (my dll does some file reading/writing)
php can't find the DLLs
The actual error I get is:
The FastCGI process exited unexpectedly.
Any idea on how to debug this problem?
The problem here is almost certainly related to file permissions.
When you run php.exe from the command line you run as your own logged-in user. When running a PHP script from IIS, in response to an http request, php.exe runs as a different user. Depending on your version of Windows it could be
IUSR_machine - on IIS6 and prior
IUSR on IIS7 and later
These users need permissions on the php file to be executed.
Read more about it
On IIS7 and later I use a command-line tool called icacls.exe to set the permissions on directories or files that need to be read by IIS and the processes it starts (like php.exe). This security stuff applies to all IIS applications: PHP, ASPNET, ASP-classic, Python, and so on.
IIS also needs to be able to read static files, like .htm, .js, .css, .jpog, .png files and so on. You can set the same permissions for all of them: Read and Execute.
You can grant permissions directly to the user, like this:
icacls.exe YOUR-FILE-GOES-HERE /grant "NT AUTHORITY\IUSR:(RX)"
You can also grant permissions to the group, to which IUSR belongs, like this:
icacls.exe YOUR-FILE-HERE /grant "BUILTIN\IIS_IUSRS:(RX)"
In either case you may need to stop and restart IIS after setting file-level permissions.
If your .php script reads and writes other files or directories, then the same user needs pernissions on those other files and directories. If you need the .php script to be able to delete files, then you might want
icacls.exe YOUR-FILE-HERE /grant "BUILTIN\IIS_IUSRS:(F)"
...which grants full rights to the file.
You can grant permissions on an entire directory, too, specifying that all files created in that directory in the future will inherit the file-specific permissions set on the directory. For example, set the file perms for the directory, then copy a bunch of files into it, and all the files get the permissions from the parent. Do this with the OI and CI flags (those initials stand for "object-inherit" and "container-inherit").
icacls.exe DIRECTORY /grant "BUILTIN\IIS_IUSRS:(OI)(CI)(RX)"
copy FILE1 DIRECTORY
copy FILE2 DIRECTORY
...
When I want to create a new vdir in IIS, to allow running PHP scripts, or ASPX or .JS (yes, ASP Classic) or Python or whatever, I do these steps:
appcmd.exe add app /site.name:"Default Web Site" /path:/vdirpath /physicalPath:c:\docroot
icacls.exe DIRECTORY /grant "BUILTIN\IIS_IUSRS:(OI)(CI)(RX)"
Then I drop files into the directory, and they get the proper permissions.
Setting the ACL (access control list) on the directory will not change the ACL for the files that already exist in the directory. If you want to set permissions on the files that are already in the directory, you need to use icacls.exe on the particular files. icacls accepts wildcards, and it also has a /t switch that recurses.
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...