9

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.

Alex Coplan
  • 585
  • 1
  • 10
  • 19

2 Answers2

18
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.

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.

Sven
  • 98,649
  • 14
  • 180
  • 226
  • thanks - my thought's exactly about the permissions - I don't really have an option to host it elsewhere as the company I'm developing for won't pay for it, and recommended me this guy and said that they'd get him to do it for free - from what I can tell I'm just running off one of his virtual servers. So how does it normally work, how can a PHP script run as a "user" and therefore be able to write to anything on the site? – Alex Coplan Dec 18 '11 at 19:03
  • Well, I would inform them about what they get "for free". I have not much experience with any shared hosting, so I can't comment on that. My sites all run Debian web servers and folders that need to be writable will be owned by `www-data` with `700` permissions, but this is likely not going to work in your case. – Sven Dec 18 '11 at 19:09
  • I think they're paying him for their main site as well so that's why - if it's any help at the bottom of any server error page it says this `Apache/2.2.9 (Debian) PHP/5.2.6-1` – Alex Coplan Dec 18 '11 at 19:14
  • also this is vps not shared – Alex Coplan Dec 18 '11 at 19:45
  • What's the name of the user you use to FTP the data to the server? – Sven Dec 18 '11 at 19:48
  • why do you need to know that? – Alex Coplan Dec 18 '11 at 19:52
  • 2
    Well, I try to figure out which what permissions and ownerships your files might be transferred to the server. If it is a user which is not at least a member of the `www-data` group, you either need to change users/groups after the transfer or indeed use `777` permissions. But this is pointless, we can't help you this way. – Sven Dec 18 '11 at 19:59
  • the use is `compapp` which is part of a group called `psacln` – Alex Coplan Dec 18 '11 at 20:41
  • +1 If this guy is running it on a virtual server and we've already established that he's an idiot, why not just pop the application onto a Linode and be done with it. At least then we can all be a lot happier knowing the root password isn't "password"... – Kyle Smith Dec 19 '11 at 04:12
  • @KyleSmith what is Linode? - Could you explain more? – Alex Coplan Dec 19 '11 at 21:22
  • @AlexCoplan: www.linode.com, it's a type of VPS. – Sven Dec 19 '11 at 21:31
  • should of googled - sorry, yeh I would love to get a VPS and have this over and done with but I can't keep paying for hosting for companies that I'm developing for - I've emailed the guy asking him to make my user a member of the `www-data` group so we'll see what happens... – Alex Coplan Dec 19 '11 at 21:43
  • ...and a free EC2 Micro instance won't work? You *need* to get off this idiot's server. Your application's uptime should not depend on the whims of some miscreant slob of a sysadmin. – Skyhawk Dec 20 '11 at 01:30
13

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.

Rilindo
  • 5,078
  • 5
  • 28
  • 46
  • 2
    Wish I could upvote twice. – Wesley Dec 19 '11 at 02:49
  • The problem is really that the website should not write to files within it's own structure rather than the permissions themselves. – JamesRyan Dec 19 '11 at 12:14
  • You're right. Depending on the data, you probably would want to write to a file outside of the public webroot. – Rilindo Dec 19 '11 at 19:41
  • Here I'm writing to a `/data` folder - this folder contains PHP scripts which make up my JSON web service, and a bunch of images used for content passed down in the web service (in a `/data/img` folder) – Alex Coplan Dec 19 '11 at 21:25
  • So the images needs to be public, then? That clarified things. – Rilindo Dec 19 '11 at 21:29