Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
12  
Run away from this guy and don't look back. –  Iain Dec 18 '11 at 18:59
    
Not really an option... see the comments on SvenW's answer... –  Alex Coplan Dec 18 '11 at 19:16
add comment

3 Answers

up vote 12 down vote accepted

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.

share|improve this answer
1  
Wish I could upvote twice. –  Wesley Dec 19 '11 at 2: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
1  
Accepting this answer because it was the most helpful - thanks –  Alex Coplan Dec 30 '11 at 12:24
show 1 more comment
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.

share|improve this answer
    
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. –  SvW 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
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. –  SvW Dec 18 '11 at 19:59
show 8 more comments

Yes my apologies, I hadn't considered execs, 711 (exec only) 755 (exec and read-only, may be a more viable option),Thanks.

share|improve this answer
    
744 disables the public from executing php scripts! –  Alex Coplan Dec 18 '11 at 19:35
    
@AlexCoplan: When PHP runs as an Apache module on Debian, it get's usually executed as user/group www-data:www-data, because it runs from inside the Apache process(es). –  SvW Dec 18 '11 at 19:48
    
@SvenW not on this server! - it's giving me 403 forbidding with 744!!! –  Alex Coplan Dec 18 '11 at 19:52
    
all I can then recommend is seperating your scripts, for user-generated content, considering this is a shared hosting and you do not own any directory's permitted to you, then you should at least try to protect your scripts as best you can. –  s1los Dec 20 '11 at 4:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.