chmod 600 didn't work as expected

episkey · #1 04-01-2008, 08:18 PM

For my baby croc account, as an experiment, I set the permissions to 600 for a php webpage that's in my public_html directory. I expected that I would not be able to view the page in my browser. Upon testing, however, I was able to view the page.

I went into Live Chat and was told that sometimes a page set to 600 can be viewed. I didn't press the matter, since I don't have a real world problem that I'm trying to solve right now. I was just testing to see if my mental model of how permissions work is correct. Evidently it is not.

But now this is bugging me. Can anyone explain what's going on?

gwyneth · #2 04-01-2008, 10:37 PM

Depending on what your browser settings are, it's possible that you were viewing the page in its pre-changed state.

gtgeorge · #3 04-02-2008, 04:38 AM

I don't think that permissions of 600 would prevent the file from being processed to be viewed. You aren't actually viewing the file?

episkey · #4 04-02-2008, 10:59 AM

Quote:

Depending on what your browser settings are, it's possible that you were viewing the page in its pre-changed state.

I checked it on another computer (on which the page and site in question had never before been viewed) with a different connection and IP address.

Quote:

I don't think that permissions of 600 would prevent the file from being processed to be viewed. You aren't actually viewing the file?

This is what I want to understand. When the client passes a request for a page to the server, does the server process that request using the permissions of the file owner and then pass the results back to the client?

I've done some further experimentation and it seems to work as above for php files, but not for txt or html files. In other words, if I chmod a txt or html file to 600 and then try to view with a browser, I get the forbidden message. However, if I chmod a php file to 600 and try to view in a browser, I see the output the php code produces.

whatrevolution · #5 04-02-2008, 03:31 PM

On HG's server configuration, the entire thing is built for the webserver to run as YOU. Your account login name you chose at signup, the one that you use to access http://your.HG.IP.here:port/~accountname ... that's the username your webserver runs as. That's the username the system gives ownership of your files to.

Your experience with 600 on .php might be because HG used the official PHP recommendation for building a PHPsuExec, PHP as CGI environment. As I understand that, although PHP code does not 'execute', it is 'parsed' by a binary which is 'executing', in the case of the official PHP CGI method, the webserver does indeed think that the .php is executing.

I'd like to be corrected on that, if I'm wrong, since I can not confirm that PHP SuExec does that, or that HG used the official method. Official way is wrong, btw. I'm not near my bookmark, but the basic flaw was AddType being used in httpd.conf, where AddHandler is correct. ThePlanet knows this, and they're HG's datacenter, so perhaps HG knows this.

According to Symfony framework docs, I should be wrong about execution permission.

According to this pdf, I should be quite wrong.

kompreszor · #6 04-02-2008, 06:18 PM

I can confirm that the pdf file is correct in the way permissions work on HG, at least on the one I'm on.

Right now I have my index.php set to 400, it's been set to this for a month, and the site works fine, I've even set the public_html to 750 and still everything works just as it should.

I'm glad this came up I've been thinking about this for a while and read over on cPanel forums about this very same thing and they say the same thing. If you think about it, anyone that found a way to inject php would have the same control as your user... *shivers*

whatrevolution · #7 04-02-2008, 08:58 PM

Quote:

Originally Posted by kompreszor

If you think about it, anyone that found a way to inject php would have the same control as your user... *shivers*

That's why I have no sympathy for the cry-babies in the PHP5 upgrade thread...

episkey · #8 04-02-2008, 09:52 PM

Quote:

Originally Posted by whatrevolution

Your experience with 600 on .php might be because HG used the official PHP recommendation for building a PHPsuExec, PHP as CGI environment.

OK, this gets to why I was experimenting in the first place. In the past I've made little use of php -- even though I like a lot of its features -- due to security concerns. With PHPsuExec now on HG, I'm hoping to feel secure enough to do more with PHP.

Quote:

Originally Posted by kompreszor

I can confirm that the pdf file is correct in the way permissions work on HG, at least on the one I'm on.

Right now I have my index.php set to 400, it's been set to this for a month, and the site works fine, I've even set the public_html to 750 and still everything works just as it should.

The permission scheme described in the pdf makes a lot of sense to me. I will happily set the permissions of my real working .php files to 400 or 600.

Does having public_html set to 750 work because the group for public_html is nobody? I've been wondering why the group is different for public_html than for all my other directories.

Thanks to all for sharing your thoughts. I lurve the way this forum is helping to move my understanding forward.