Permission denied - PHP screw up?

[Anon]

I recently switched web hosts and now I keep getting an error message -- permission denied -- when I try to write or append to a file on their server.

I've been told it's the way they have installed PHP. Sounds like bullsh!t to me. I own the file and permissions are set to read and write. And I never had this problem with my former web host.

Anybody know the truth here? If I can't get this resolved then PHP is history for me. This had got to be the dorkiest issue I've run into in a long time. Who needs a web site you can't write files to? This is like having a floppy disk with the access tab glued shut.

[Anon]

I know you're pissed your account doesn't work, but there's no need to take it out on us or PHP.

This is a simple administrative issue.

Did you know that unless otherwise configured, both windows and unix/linux run the web server as a user that generally doesn't have write permissions to the user directories?

Apache has support for what's called SU-EXEC functionality, where the daemons serving from a given directory will run as the owner of that directory.

Another option would be for you to create a directory you want to write to and set it to 777 permissions, and let it write there. If it's a level down in your hierarchy, then you're probably safe from hacking, but really, this is a problem for your sysadmin at your hosting company to handle.

[Anon]

Live & Learn! One never knows what might happen when switching web hosts. The lesson to be learned here is when you are happy with your web host, stay with them, unless they've priced themselves out of the market.

In view of what you wrote, I have a question. What about writing to a database? Since a database is nothing more than a collection of files, then how is this issue about permissions resolved? Why is it premissible to write to your database, but not your flat files?

[smarlowe]

Because the permissions to control the database are handled by the database, which isn't really related to the unix file systems permissions.

Fer instance, in Postgresql, there's usually an accout named postgres that runs the database and owns all the files underneath it. when you insert a row, the postgresql database checks to make sure you are you, then writes that data to the database as your data. But the file it writes it to belongs to the postgres user, not you. In order to get it back, postgresql has to again check who you are and decide if you have permission to read the data. If so, then IT reads the data from it's own db files, and then delivers it to you.

The point you make about hosting companies is QUITE valid. They are not interchangable, and if they can't figure out how to configure apache to run wtih su-exec support on user directories, then they really don't deserve your money as a host.

For larger sites this can be overcome by having your hosting provider set up a single machine, just for you, and giving you the root password to that box. Costs more since you aren't sharing it with other people, but guarantees that some kid running a pr0n site won't kill your site with overload either.