I have a question about file permission in linux .
Let's suppose I have hosted a index.php file in my machine. The file can be read in browser.But I wanted to make it such like it should be viewable in browser but should not accessible from my machine.
Is there any way so I can restrict someone to access it from my machine folder but can be read via browser?
P.S:- He/She has a low privileged shell.
The webserver runs as some user, for example apache. Make the file owned by apache with permission 600. This makes it available to user apache and no-one else.
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.
I am working a LAMP web app running on Ubuntu 11.10.
I followed instructions on the web to harden my apache, php and mysql.
I have a PHP script which work fine when I run from the command line under my own id. But when I put the scripts into the web app framework, it can't not even open a log file to write (in /tmp) and it can't read other files in /var/www/myapp/html as well.
I used Ajax to retrieve file contents on the server and then serve those files to the browser. So my url will look like: "php/myphpscript.php?arg=.......".
My directory structure is
/var/www/myapp/html|php|js|cfg.
I know this problem has something to do with permission, security but I am quite at loss.
Can someone describe what I need to do here?
Thanks,
I suspect you copied the files with your username, but apache executes as user www-data an thus has no access to your files. Either change them to belong to the apache user, or if you are the only develper on this machine, cahnge apache to run as you.
What is the safest chmod for a web app to write into a simple .txt file, and it should not be accessible by the public.
Thanks,
Jean
Do you mean not accessible to the public via a web server? You would need to use a .htaccess file to limit access.
PHP will most likely be hosted through the apache process or as a CGI probably running under the same user as the apache process, so chmod wouldn't work in 90% of cases.
If your PHP process runs as another user, you can only allow r/w for the public. But if you mean not accessible by the public through your web server, you can use .htaccess do deny access to it.
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.
How can you allow a PHP script to write to a file with high-security restrictions, such as only allowing a single user to write to it?
The difficulty seems to be that a PHP script is running as a low-permissions user (maybe apache, or www, or nobody?), and even if I chown apache the_writable_file, the directory it's in might not be writable for the low-level user. In general, what's the usual way that PHP can work with local files in a secure way?
Unfortunately, in shared hosts that use mod_php, there is no way to restrict access to secure files to your web app and login user.
The solution is to run your web app as your login user. When you do that, UNIX file permissions can correctly lock everyone else out. There are several ways to implement that, including SuExec, suPHP, or running PHP with FastCGI with mod_fcgid or mod_proxy_fcgid. FastCGI is my favorite way.
Another solution is to use a dedicated host or virtual private server.
Sure, chgrp apache the_writable_file and chmod g+w the_writable_file. After that, only your secure user and the apache user will be able to write to the file. Since the apache user is typically forbidden from logging in, you only have to worry about web users writing to your secure file using through the http daemon.
All the containing folders need to have execute permissions.
For example, if the file's in /foo/bar/the_writable_file, the directories "foo" and "bar" both need to have executable permission to access the_writable_file, even if they don't have read/write permission.