Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

PHP Guest Book, CHMODing/file permissions question

scem0

scem0

macrumors 604
Original poster
Jul 16, 2002
7,028
1
back in NYC!
I'm not much of a programmer, but I'm working on a guest book for a wedding website for my sister. Right now the form that users fill out to post to the guest book has three fields - "name", "email", and their message. I store all these values in a single text file, which I read from when I display them on the front end of the guest book.

My problem is that I don't display the email addresses, but I want them to be available in the 'Administration Panel' for my sister's convenience.

I use a standard fopen to access the file, to convert the data to HTML. I've found that the fopen doesn't work at all unless 'public' is set to 'read' in my CHMOD (777 for example). But when my data file is CHMOD'd to 777 then anyone with an internet connection can access those files by directing their url to the text file. So my natural thought process (knowing little about CHMODing) was to make the permissions 666, which would give the 'owner' (who I assume is me and my files on my server) access to the data file, but 'public' would be denied access. Sure enough, when I CHMOD to 666, I get my desired "403 forbidden", but then my script can't access the file to read the data. It's as if the file thinks my script is a 'public' script.

I hope that made an tiny bit of sense to someone other than myself. I don't really know what I'm talking about which makes it hard to describe my situation :).

Help is greatly appreciated, so thank you ahead of time!

e
 
PHP's fopen() depends on the ability of the web server to read the file. Apache runs as a certain user/group - usually www/www. If that user/group can't read a particular file, it won't be able to serve it, and fopen() won't work on it.

I would take a different approach to protecting the file. I would create a .htaccess to ensure that it is not read. Such as:

<Files sensitive-email-addys.txt>
Deny From All
</Files>

Web browsers won't be able to see it, but the web server will still be able to write to it.

By the way, 666 is rw-rw-rw-, 777 is rwxrwxrwx. Those are both very dangerous permissions for a public file on a webserver to be because they theoretically allow anyone to write to the file.
 
scem --

in general, you want your file permissions to be 755 for executables and directories, and 644 for "plain ol'" files. unless you don't want anyone to allow anyone but the owner access, then you want 700 and 600, respectively.

regarding the whole php permissions thing, you want to run this on a host that has phpsuexec implemented. reason being: w/o it, the process running all the php commands belongs to user apache, but your files belong to the account owner. therefore, the permissions must be world-writable for apache to write to them. and as you've mentioned, that means anyone can write to them.

under phpsuexec, those processes are owned by the user of the account, which is correct behavior. this allows you to use 755/644 and still have everything work.

so my advice is to find a new host that runs phpsuexec on their servers (i recommend hostgator.com).
 
Nobody here has thought of the security implications of having the ability to modify the filesystem?

Clearly not.

scem0 - Here is my best advice. You shouldn't be using files on the web server to store this type of information. You need to use a database.
 
SC68Cal said:
Nobody here has thought of the security implications of having the ability to modify the filesystem?
Click to expand...
i agree a database is better, but if the phpsuexec stuff gets sorted out, and the flatfile is made 600 -- what's the security concern?
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back