I'm relatively new to web development, so please be patient.
I'm primarily an iPhone developer, but have recently done a site for someone else using shared hosting. I could write to files in PHP on that site fine, without having to think about permissions.
I'm in the process of deploying a web service for a new app I'm making, but it's not really going smoothly. The most important difference here is I'm using someone else's server, and just have FTP/DB access.
Basically, I have a load of PHP files which make up my CMS, like so:
mysite.com/admin/manage_news.php
mysite.com/admin/manage_events.php
Those scripts then either edit the database, or files. They can interact with the DB fine, however, my scripts cannot write to the filesystem. They might, for example, attempt to write to the following files:
mysite.com/data/img/event_1.png
mysite.com/data/somefile.txt
This worked fine on my MAMP install (locally), but once deployed to the server, PHP spewed out errors everytime a write was attempted... something like this:
Could not open file "../data/img/someimage.png" for writing.
So I emailed the guy who's running the server, and he came back saying:
Does it work with public permission? (777)
And, it did - but I was very cautious with using public permissions, so disabled it straight away again. I emailed him saying "how can I make my PHP scripts write using standard user permissions", and he said:
Leave it as public, it'll be fine
I reckon it's an ip conflict somewhere in the domain resolution, but I'm not worried about it.
I then emailed him saying "surely this is insecure" or something along those lines, and he replied with the following:
the reality is that there are millions of website, including several that I manage that have 777 on various folders, it's just a way of life.
Could anyone give me some idea of a solution I could give him? Or what I can do to avoid having to use 777? I really don't like the idea of any folders on my site/service to be publicly writeable.
I would very much appreciate your advice as I know very little about web servers.
This guy is an idiot and this is complete nonsense. Access rights have nothing to do with IP addresess or domain resolution, he is just dropping words.
Given the quality of this "administrator", I would recommend to host your site elsewhere as it is very likely the site is administered very poorly and insecure. Just putting
777
permissions on something so that it works is a sure sign he doesn't understand a bit of what he is doing.What access rights are really necessary is dependent on the way the system is used and configured and it is kind of hard to tell you something without knowing this.
Let's break it down:
You need the user running the script to read, execute and write on the directory, so it should be:
7 = (r)ead,(w)rite,e(x)ecute
Other users belonging to the same group should be able to execute the php file within the directory, but not write to it (for obvious reasons); they don't necessarily need to read the PHP files. Therefore, we need to provide just execute permissions:
1 = e(x)ecute
Same for the public. In fact, that's all you need for external users who need to view php and static files:
1 = e(x)ecute
So the bare minimum should be:
711
I confirmed the above settings with my own configuration, so it should work; however, this is under the default web user. If you are uploading with a login other than www, the files and directories would probably be under a different user. In that case, the default web user may not be able to read or write the files that are owned by you. At that point, you probably need to add the default web user to your group (the sysadmin will have to do that) and then give read, write and execute permissions to users belonging to the group:
771
And that would probably work. Either that, or have the sysadmin change the user and group ownership of those files to the default web server user (but NOT THE PERMISSIONS!). If that still doesn't work, a sample output of the permissions (something like "ls -la within the directory") would help us troubleshoot this further.That said, as long as you only have to give execute permissions to the public (or "other"), you should be fine from a security standpoint.