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)
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 PHP file, x.php, that outputs b.xml every time it is run. The way I do this is by using crontab to run the x.php file. The problem is that due to the server's settings, the new file has permissions of 400. So I also have another crontab line to change file b.xml permissions to 777 so that x.php can run over it next time.
I feel like I am making this too complicated. Is there any way to make this a bit simpler?
Quick Answer
You'll need to chmod the file to be 777 in the x.php script.
After b.xml has been created, run this line:
chmod('path/b.xml', 0777);
Note you should always specify octals when using chmod.
A better way?
When you run a cron job, you should take special note of the user that is running the cronjob.
Generally on a shared server you will have your own login and thus the cron job runs as that user. My question to you - is that user the same as your web server? often php runs as "apache" and cron might be running as "tanner". In that case, setting b.xml to be owned by tanner, and having a permissions 400 means that only tanner can change the file.
To solve this, if you don't have access to umask, one way would be to change your cron job to run as the webserver:
su -c "php /home/jonathan/public_html/b.php" apache
This may or may not work depending if you are allowed to switch to apache as the user. do not forget to switch apache to the actual web servers username.
Now, if that doesn't work, then the alternative is to go for the 777 permissions. Keep in mind on a shared server this means anyone on that server could potentially get to that file if they knew the path.
Another way as suggested by OP:
0,10,20,30,40,50 * * * * /usr/bin/wget http://example.com/user/x.php
This way will always run as the apache (or whatever) user that apache runs as, ensuring the next time it is accessed, the file will be useable.
Ask the server admin to create a new user who owns the folder where the script writes the xml file.
Run your php script through your cron job as such user. If you run your script as the folder's owner you might change the permissions through your php script.
This should work:
// set permission
chmod('path/to/b.xml', 777);
// do other stuff
To solve this issue, I ended up just creating a cronjob such as this:
0,10,20,30,40,50 * * * * /usr/bin/wget http://example.com/user/x.php
This executed the file which created b.xml and since the user who executed the script was public, the permissions remained public as well.
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?
I'm trying to use this Dagon Design PHP form to help a local non-profit publication enable their readers to submit photos. I've got the "mailer" part working -- the notifications work fine -- but the "saving a file to a folder" part isn't functioning.
On the form page, the author says "the directory must have write permissions," but I'm not sure "who" is writing to that folder -- is this PHP script considered "Owner" when it saves something on my site? Or do I need to allow save permissions for Owner, Group and Others?
I'm not sure why the script isn't saving the photos, but this seems like a good place to start. I've tried looking around on Stack for answers, but most questions seem to have to do with folder creation/permissions.
The page I'm clumsily trying to build is here, if that helps.
As Jon has said already, you don't want to allow write access to everyone.
It's also possible (depending on the hosting) that something like suEXEC is being employed - which will cause your PHP script to run as a user other than the webserver's (as reported by Dunhamzzz).
Probably your best approach, in my opinion, is a script calling whoami:
passthru('whoami');
Or alternatively you could try:
var_dump(posix_getpwuid(posix_geteuid()));
Bear in mind, this does give system information away to the world - so delete the script once you've used it!
Then, as you've correctly asserted in your question, it'll likely be the file permissions.
If you do have CLI access, you can update the permissions safely as so (first command gets the group)
id -n -g <username>
chmod 770 <directory>
chown <username>:<group> <directory>
(You may have to pre-pend "sudo" to the "chown" command above, or find other means to run it as "root"..., reply back if you get stuck.)
If you've not got access to run command-line, you'll presumably be doing this via a (S)FTP client or the alike. I'm afraid the options get a little to broad at that point, you'll have to figure it out (or reply back with the client you're using!)
As always, YMMV.
Finally, bear in mind if this is your own code, people will at some point try uploading PHP scripts (or worse). If that directory is accessible via a public URL ... you're opening the hugest of security holes! (.htaccess, or non-document root locations are your friend.)
If you are not sure how is your server configured (and this would influence who's the final file owner) then add write permission to anyone (chmod a+w folder), upload one file and ls -l to see the owner. Then you can adjust permissions to allow write access to certain users only
The PHP script that saves the files is running with the privileges of some user account on the server; the specific account depends on your OS and the web server configuration. On Linux and when PHP is running as an Apache module this user is the same user that Apache runs as.
Solving your problem reduces to determining which user account we are talking about and then ensuring that this user has permission to write to the save directory (either as owner or as a member of the group; giving write access to everyone is not the best idea).
You'll need to set the permissions of the directory to that of the webserver (probably Apache, nginx or similiar), as that's what is executing the PHP.
You can quickly find out the apache user with ps aux | grep apache, then you want to set the permssions of the upload directory to that user, something like this:
chown -R www-data:www-data images/uploads
I have a PHP script that is accepting all emails (wildcard) to my domain, and inserting the data into MySQL.
The beginning of the script has this line:
#!/usr/bin/php -q
It then looks like a regular PHP script. The part that writes the attachments to disk seems to work but the permissions on the new folders where they're stored were created by the 'nobody' user.
How can I edit permissions so that after these files are written to disk, they can be accessed by the webserver/webserver user?
Thanks for the help!
(Fedora 14 Linux server, Postfix)
You can preform your file system operations by FTP so you will have the same permissions as your user.
its better then give all the PHP users on server access to your files.
http://php.net/ftp
What user is PHP running as? PHP does have a chmod function, but you can't elevate privileges higher than what the user PHP is running as.
If that doesn't do the trick, could you chown the attachment directory to be owned by whatever user PHP is running as?
I suggest you do the following:
chown -R apache:apache directory_name
This is because PHP runs as the web server user (I believe this is apache on Fedora). Otherwise, if you are using a different web server, then change the ownership of the files to that web server's user (you are sure to find this in the server's configuration files somewhere).
You need sticky bits on the file server level.
setting the sui/sgid bits