PHP Guest Book, CHMODing/file permissions question


macrumors 604
Original poster
Jul 16, 2002
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!


Super Macho Man

macrumors 6502a
Jul 24, 2006
Hollywood, CA
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

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.


macrumors 601
Jul 18, 2002
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


macrumors 68000
Feb 23, 2006
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.


macrumors 601
Jul 18, 2002
Nobody here has thought of the security implications of having the ability to modify the filesystem?
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?