PHP Guest Book, CHMODing/file permissions question

Discussion in 'Web Design and Development' started by scem0, Aug 11, 2007.

  1. scem0 macrumors 604

    scem0

    Joined:
    Jul 16, 2002
    Location:
    back in NYC!
    #1
    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
     
  2. Super Macho Man macrumors 6502a

    Super Macho Man

    Joined:
    Jul 24, 2006
    Location:
    Hollywood, CA
    #2
    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.
     
  3. zimv20 macrumors 601

    zimv20

    Joined:
    Jul 18, 2002
    Location:
    toronto
    #3
    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).
     
  4. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #4
    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.
     
  5. zimv20 macrumors 601

    zimv20

    Joined:
    Jul 18, 2002
    Location:
    toronto
    #5
    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?
     
  6. SC68Cal macrumors 68000

    Joined:
    Feb 23, 2006
    #6
    If you don't sanitize your app well enough they will be able to execute arbitrary commands.
     
  7. zimv20 macrumors 601

    zimv20

    Joined:
    Jul 18, 2002
    Location:
    toronto
    #7
    details, please.
     

Share This Page