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.
Related
I have a folder above the webroot that is used to temporarily store user files generated by a php web application. The files may, for example, be PDF's that are going to be attached to emails.
The folder permissions are set to rwxr-xr-x (0755). When executing a procedure from the web application, the files get written to this folder without any issues.
I have now also set up a cron job that calls the php script to execute that exact same procedure as above. However, the PDF cannot be saved into the above folder due to failed permissions - the cron job reports back a permission denied error.
I have tried setting the folder permissions to 0775 and still get a permission denied. However, when the permissions are 0777, then the cron job then works fine.
This seems very strange to me - why does the cron get a permission denied at 0755 but it works fine through the web app?
The probable answer is that the cron job executes under your user - and the directory is owned by apache (or www-data or nobody or whatever user your web server runs as).
To get it to work, you could set up the cron job to run as the web server user.
Something like this:
su -l www-data -c 'crontab -e'
Alternatively, you could change the permissions to 775 (read-write-execute for the owner and group, and read-execute for others) and set the group ownership of the folder to the user running the cron job.
However, you have to make sure that if you're deleting something or descending into folder which is created by apache, you could still run into problems (apache would create a file which it itself owns, and your user cannot delete it then, regardless of the directory permissions.
You could also look at some stuff like suphp or whatever is up to date - where the web server processes are ran under your username, depending on your system architecture.
It depends on which user you have defined the cronjob.
If you're root (not recommended) it should work. If you're the web-user (e.g. www-data on ubuntu) it should work as well.
sudo su - www-data
crontab -e
Permission are given to user-group-everybody. That's what the 3 characters denote.
Your php script runs as a different user&group than the cron job, so they observe different permissions.
Check chown and chgrp, or try to run the cron job with the same user.
if you are using cpanel to run a php, you can try something like this:
"php /home/algo/public_html/testcron.php" ...
just write: php (the rute of the script)/yourscritpt.php"
I am trying to call a python script from php (Using xamp).
The python script internally calls a shell script and the shell script has an ssh and scp command.
On executing the PHP back-end code using exec I observe the following errors in xamp log file.
The python script works fine through command line
Could not create directory '/sbin/.ssh'.^M
Failed to add the host to the list of known hosts (/sbin/.ssh/known_hosts).^M
Permission denied, please try again.^M
Permission denied, please try again.^M
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).^M
Could not create directory '/sbin/.ssh'.^M
Host key verification failed.^M
Presumably, the python script is being run by a different user when it's called by PHP than when you run it by hand, which does not have appropriate permissions to do whatever actions the script is trying to perform. So you'll need to tweak permissions / user groups for the various things the script is going to be trying to do in order for it to run successfully.
Looking at this question is probably a good starting point:
How to check what user php is running as?
Once you identify the user that is actually running the script, you can try running the script as that user and then fixing problems as they come up.
I couldn't say for sure without seeing the Python script, but this probably has something to do with what the working directory is when the php user calls the script. You should either use absolute paths in your code or use
os.chdir(<path>)
to make sure you're using the correct working directory. Note if you do this, you'll probably run into permissions errors as mentioned in the other answer since .ssh and files in it are usually accessible only to the user whose directory it's in.
I've assumed that if my php script has permissions set to root, the script would be able to execute commands as a root user. But apparently, it's not the case. I noticed that I cannot write anything outside of www and when I want to write a text file at /test.txt, it won't create a file because of permissions at / saying that non-root users only can access but not create or delete but the script itself has the root permission. If I change permissions at / then it works fine. Why can't my php script, set to have root permissions, write to the / directory?
And what can I do to enable the php script to be executed as a superuser?
I want to use the exec() and I cannot seem to get it to work. I want to be able to create a crontab and it doesn't work. I wrote a code like this:
exec("crontab -l > test.txt; echo '* * * * * echo hi! > /root/Desktop/hi.txt'>> test.txt; crontab test.txt");
But it won't work. If I copy the string into terminal, it works as expected.
Setting the permissions on the script file itself does not affect who the script is run as. it affects who can access the script.
To run the script as root, it depends on the context. Are you running it in a web server or is this a CLI script? If the later, then you must run it while logged in as the root user or with the sudo command. If its in a web-server as apache, then you must configure apache to run as as root but this is highly discouraged as it opens up a lot of security risks.
The permissions/ownership of a script have no bearing on which user that script runs as. It will run as whichever user executes it, assuming it has permission to do so. Sometimes you can use the setuid 'sticky bit' permission to do things like this, but most systems do not allow it, and the least offensive term I can think of to describe allowing it is "inadvisable".
I noticed that I cannot write anything outside of www
Because apache is configured properly. Ideally it will run as a non-root users [usually www] and any scripts will run as that user as well. Instead of telling you how to configure apache to be less secure why not just grant the apache user access to the file/directory that you want to access/modify?
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 a PHP script which changes file permissions on my server using chmod. I'd like to be able to run the script both via the browser (as nobody) and via a cron job (as username).
Is it correct that only the owner of the file can change the permissions? I.e. if I create a file via a cron job and set the permissions, I can't then change those permissions when running the script from the browser?
Are there any ways round this please? Delete (unlink) and re-create the file as whatever user the script is running as? Or is there a way of running a php script via a cron job as nobody? / via the browser as username?
The aim is to be able to make images publicly viewable or not by changing the file permissions.
Solution 1: Create a group for both the user and the cron user, add each user to your new group, and give both users access to read and write to the file (chmod g+rw filename). (safer then the next solution).
Solution 2: The simplest way to do this is to make the file readable and writable by everybody (chmod a+rw filename) would have this effect.
I would not recommend this for production usage though.
You can do this without putting a username or password in your script.
In your crontab have sudo execute the script as the user that your web server runs as. Following your example, I'll use the nobody user.
0 12 * * * (sudo -u nobody php ./yourscript.php)
Note that the "nobody" user (as well as users like "apache") do not normally have login privileges. This may require you to allow sudo to execute scripts without a tty. You'll know this if you receive an error like: "sudo: sorry, you must have a tty to run sudo"
Allowing this can be done by commenting out the "Defaults requiretty" line using the visudo command. As with any change to sudo, you may want to search for any side-effects this change may come with.
Yes, only the owner of the file can do this. Your options depend on what kind of control you have over the server.
If you have enough control over the server, you can use SuPHP instead of Apache's mod_php. That way, the PHP scripts will be run as the user who owns the script, and any files created by a PHP script will be owned by the same user.
If you don't have that much control (common shared web hosting, for example), you could use something like Joomla's FTP approach. When FTP support is turned on in Joomla, it does all file manipulation using FTP. That way, it can create or manipulate files with the same permissions as the FTP user.
Something like this (error handling ommitted):
$ftp = ftp_connect('localhost');
ftp_login($ftp, 'username', 'password');
ftp_chdir($ftp, '/root/to/website');
ftp_chmod($ftp, 0644, 'filename.ext');
ftp_close($ftp);
Only the owner of the file can do this, I would recommend running the cronjob as 'nobody' instead.
Usually only the owner or the super-user (or equivalent)