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.
Related
I have an Apache server
I have several SQLite databases there
I have a PHP code there
I have an Android application which communicates with that PHP code (http post)
The PHP code gets data from the Android application and creates SQLite databases or write records there or read and so on
So the complete control over SQLite databases is with that PHP code
Now the questions are as following:
1 - Considering the file-folder access permissions, what is the PHP code called,
owner or group or world ?
2 - Is it a true structure that all users interact with that PHP code and whenever an Android user is working with the SQLite database of the server, that PHP code gives Write-Read access to the folder containing the SQLite database?
3 - Isn't there any conflict considering one user may give write access to the folder containing the SQLite database and one other user which previously had given write access has now finished the work and gives read access to the folder? while the first user needs write access yet and the other user has now changed it to read access?
4 - Isn't there any security issue if I generally give Read and Write access to the folder containing the SQLite database (Since the PHP code controls everything and I have the PHP code in non public html folder of the server)
PHP runs through a webserver, the webserver runs under a user account, access to the servers file system (usually linux) is restricted to users/groups.
So, access to a folder/file must be possible for the user account (on that server) who is running the webserver process (which is running the PHP executable).
The SQLite file should NOT be accessible from the web.
It's not that access rights are changed by the PHP process according to web-users making a request. You should make yourself familiar with how the web actually works...
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.
In my PHP application I am using file_put_contents() to create a file to display comprising of a blob retrieved from a table in my database. However, currently, in order to get the function to work on my Amazon EC2 Ubuntu instance, I had to give the folder it's writing to 777 permissions. However, I know this is extremely bad and I want to change this, but I don't know what to.
I'm a novice at Linux and I'm currently navigating around my instance through the help of Google. This is part of a university assignment, so I can't just hire a Linux expert (just in case one of you says I shouldn't be using such an instance if I don't know Linux!)
Assuming that you are using this from a browser with normal http requests, you need to find out what the user is that is running the web-server. Probably something like apache, www-user or something similar.
Then you can do 2 things:
Change the ownership of the directory where you want to save the file to the web-server user and then it can have permissions 755
Change the group of the directory to the group of the web-server and then the directory needs 775.
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.