I'm using Laravel 5.1, with Log set to be generated daily.
I'm heavily using Jobs. Web server is Apache, so therefore PHP is executed as apache user, so at the end of the day, a new log file is generated by apache user and file permission is 0644. I've workers configured via Supervisor, which is being run by apache user. (So far so good)
Now for a random spike in Queue, I've a script setup to run more worker (Consumers of Queue). Problem I'm facing is since Log file is generated with 0644 permission, other users doesn't have write permission to file.
Few solutions I can think of is -
Start worker from root user (can't do, as I don't have permissions)
A cron to change file permission to 0646 at 00:00:00 each day (also requires root)
Generate Log file manually at 00:00:00 by current user, so that I would have authority to change permission to 0646 (Can't be reliable, what if apache creates it first)
Start the worker as apache user (Since no root, so this is not possible)
This Question on Unix SE Site
So my question is what is the best way to do it, it looks like a general problem to me, which any developer could face. Or is there any better way to do this apart from above mentioned methods.
[..] other users doesn't have write permission to file.
Are you sure you want those users to access the file directly? You could just add an API to your laravel app to serve this file (or even only some filtered data from it). This also allows you too have more fine grained access control within your app etc.
Related
I am currently attempting to write a simple web page to store emails in a database. I am on a server which is not mine (but does run Apache), so I do not have root access, so I have opted to use SQLite3. The goal is to use PHP to INSERT into the database, however, I continue to encounter the issue with the database being owned by me and the PHP attempting to access using the user "apache" which leads to a "readonly" error. Since I am not root, I cannot chown the database file and even when I chmod 777, it has no effect. The conclusion I came to was to have the PHP script create the database itself (under the user apache) but now I do not have write access to the file. Is it okay for me to just allow apache to own the database or is there some better way to do this?
SQLite is a library, i.e., it's just a bunch of code that runs inside the web server process. This means that accesses to the database file behave just like any other file access from Apache.
The web server process needs to be able to access the file itself, and to create the journal rollback file in the same directory.
chmod 777 is a bad because every user on that machine can do anything to the database. It would be a better idea to have the database file and the directory belong to a group that has you and apache as members.
If the server's administrator will not create such a group, then you could have apache as the owner, and add a backdoor (sufficiently protected) to your web app to allow overwriting the database with a new file.
With a PHP application deployed on Elastic Beanstalk, EC2, I've been using git and eb to manage my environment instances and all files. I need to change the permissions on a file directory to make it writable but git doesn't take care of transferring directory permissions. What's the simplest/fastest way to get this done from a mac?
Filezilla takes a long time to configure. I can SSH into my EC2 instance but still not sure how to change the permissions for my directory.
Login via SSH and type next.
Change permissions:
sudo su - # log-in as superuser*
chmod 755 /path/to/your/directory
# If you just want to allow Apache to write in directory then set 666 permissions
**If you're an owner of directory, you don't need to log-in as superuser.*
Change the owner if you need:
sudo su -
chown user:group /path/to/directory
UPDATE:
Thanks to jamieb for the correction in comments. Really I've unswered to particular gtech's question:
how to change the permissions for my directory
But of course in my opinion it's better to give permissions to e.g. apache (or www-data) user to that directory which you want to write in, to avoid such problems.
You have to do this from within your application itself. In your case, it would probably make the most sense to throw a try/catch block around the write operation and if an exception is thrown, adjust the permissions using PHP's chmod() function.
FYI, there's a pretty good chance that you don't want to be doing this though. Persistent data needs to be stored either in your database or S3 (in the case of files). Storing data locally in each instance's filesystem is a good way to lose that data the next time you do a code deployment, an autoscale event happens, or your rebuilt the environment. It can also cause problems because you're never sure which instance serves each request due to the Elastic Load Balancer.
I'm creating a web app (php) that handles the creation of Drupal sites on a live server.
The system is able to create new sites and give some maintenance on existing ones. And, as this is a web-hosting environment, each folder may belong to a different user.
In order to do that properly I need to let the apache user run some commands as some other user.
What I do to create new files (and interact with git/drush/etc) is something similar to:
$some_command = `echo "PASSWD" | sudo -u USER -S do_something 2>&1; echo $?;`;
I already have a set of commands on the sudoers file that the apache user can run as the git user.
My issue now is that I need to let apache run as ANY user that may have a hosting account on the server.
My idea was to create a apache ALL=(ALL) ALL entry on the sudoers file. I would still leave all those commands asking for the users password.
With that in mind, is this wise to go with this approach? And if not, maybe I could apply the "allow all" policy only to the users that have a hosting account. If so, how do I narrow the policy to only one group?
Thanks
Edit: I though on using suPHP for this, as it allows apache to run each PHP script as its owner. But I would still need to run some other commands as another user (as creating files in someone else's home folder/public_html), so it seems that it isn't an option.
Based on our discussion in comments, I would advise installing something like suPHP so that each of your user's scripts are owned by their actual user and not Apache.
I figure you are having this issue is (maybe) because you want to be able to perform the administrative functions of other user's sites from a web interface. If you have a generic user like apache that other users can run scripts as, allowing that user automatic sudo permission is a bad idea since it could easily be exploited to gain unauthorized access.
To get around that, make sure you run your administrative functions as a special admin user that has permission to modify other people's files. Also make sure to chown any files you create as the appropriate user so they can read/write them. And as long as no other users can access that admin account or run PHP scripts as them, you should be much safer.
If you're running the admin functions from the console then it should be even easier, otherwise just set up a suPHP user to run your master functions from the web and use good credentials for the account.
Doing something like that will be more secure and should allow you to do everything you need without opening things up more than necessary.
Solved
I figured out who the current user was using PHP and managed to set the new directories' owner to be the user the PHP scripts are executed from. However, this was still causing issues as some other commands (used to determine who the current user was) weren't working. This highlighted that the problem was that my PHP distribution was configured to be in safe mode.
I disabled safe mode and the commands provided by Ed Manet allowed me to add/edit/remove the files as desired, without the shortcut of just having everything be 777 permissions.
Thanks for the help!
Original Post
I have a web application that stores some data on the server. This involves creating and removing both directories and files (as well modifying existing files) in PHP. The main problem I'm having is do with the permissions required to perform such actions.
If I set existing files' permissions to 777, then the PHP script can edit them just fine (although I know this isn't an optimal solution as it's insecure). The script can also create and remove directories just fine (when they have 777 permissions at least), but no matter what I do I cannot get the script to create new files.
I've done some searching around and it appears that I need to elevate the PHP "user" to a user that has the required priviliges. However, when it comes to server configuration and permissions I'm essentially a beginner. How would I change to a different user to perform the required actions? Is it possible to do this mid-script and use PHP's fopen() and chmod() functions as normal? Or would I have to spawn an entirely new process using a shell command, somehow getting that external program executing with the correct privileges?
To summarise, I need a new of creating, modifying and deleting files/directories in a we b server using PHP, by assigning adequate permissions to the files and privileges to the PHP user. I am unsure on how to do this.
Thank you.
What I would do is change ownership of the folder that the PHP has to create files in to the account that runs the PHP process. Then you don't need to open up permissions so much.
So if this is a Linux system and the webserver is run by a user called "apache":
chown -R apache /path/to/the/files
Then change permissions to owner read/write
chmod -R 644 /path/to/the/files
When I download a file with curl through php I cannot seem to be able to delete it afterwards through ftp. I can delete it through the php script, but that's not exactly perfect. If the file isn't downloaded via curl, but still via php I can delete the file, it's just ones downloaded via curl that I cannot delete. When I try to run chown() through php on the file it gives me a permissions error. I've tested the same php script on multiple other servers and it works fine there, it's just this particular one it doesn't work on. Maybe it has something to do with php configuration and permissions but I'm not 100% on that.
Sounds like it is saved with the file owner being the user account of the web server. A non-privileged account can't chown to a different user, either, so that explains why chown fails... Try having PHP execute chmod 777 on the file before you delete it.
When you create a file it is usually owned by the Apache user (or whatever app server you use). The FTP user however is not the same one most of the time. You can fix this by adding the FTP user to the Apache group (or the other way around). Sometimes they already share a group (like on many plesk environments) so making files readable and writeable for that shared group may solve the issue.