installer

Well! Learn something new every day! Thanks!

Hm...could you point me to some documentation on this? Everything I can find makes it clear that the Apache php module is NOT used, that php needs to be installed as CGI. http://www.digitalpulsehosting.com/support/kb/view/article/9/

Well perhaps I’m just misunderstanding some of the various posts I’ve read regarding phpsuexec. I suppose it does make PHP files run as CGI, but I’m still unclear on this, as I can’t find any official documentation or information about it.

Ok, from what I’ve found you can’t use the Apache mod_php module, nor can you use the CLI installation; you have to use the CGI installation of php (it has to be compiled that way), and use the phpSuExec module (I forget exactly what it’s called) for apache. There are a couple of other ways of doing this; apparently Apache has its own suExec modules that can also be used, but the phpsuexec module is php-specific.

It has some interesting issues; for example a file or folder CANNOT be 777; this breaks some scripts that automatically set things to 777 on installation; and it also seems to be breaking some .htaccess php settings. Still, I think the added security of not having your folders hanging out in the wind to any script kiddie hacker on your 200+ user mass hosting server would be well worth it.

Right, I just looked at the phpinfo for my server and sure enough, it’s compiled as CGI. In any case, I do love the added convenience of never having to worry about chmodding my config or other php files now. And I bet that does play havoc with some script installers, but the added stability and security on the server are worth the several hours I had to spend moving php directives to php.ini files from .htaccess and re-tuning permissions on some old *Nuke sites.

OK, could somebody decode this?

php as regular install vs cgi install

I don’t get it. I can understand the security side of it but not the theory.

In Unix, Linux, OS X, etc. a program runs as a certain user, usually whoever installed the program. If it wants to write to a folder that is owned by another user, it can’t unless file permissions have been set to do so. File permissions are read, write, and execute, for owner, group, and world. If a folder does not have execute permissions, you can’t open it to view its contents. If it doesn’t have write permissions, you can’t create new folders or new files in it.

Apache is assigned a user when it’s installed; by default the OS X installation uses user www, and group www. So that means any scripts run by the apache mod_php will be run as www. If my folders and files are owned by me, that means that php scripts can’t write to the folders unless I change the permissions to allow world write (777 is the binary representation that is world read, world write and world executable).

su is a program in the *nix world that allows you to run a program as a different user; it’s usually used to run a program as "root" user. In the *nix world, it’s not common to run as "superuser", as it is in the Windows world, although Windows can (and should!) be configured for different users. suExec is an apache module that lets you change the user that a script is run as; it’s usually used for perl cgi scripts. The phpsuexec module allows apache to call the external CGI version of the php interpreter so that it runs as the user who owns the script being interpreted.

This means that I don’t have to have my folders and files set to have world write permissions; since my hosting company sets my part of its server so that I own the scripts, the php interpreter is run as my user, thus it has my access permissions, and nobody else can write to, edit, delete, or otherwise mess with my files and folders. They still have to be world-readable, or Apache won’t be able to read them to send them to the php interpreter in the first place!

Consider that most shared hosting servers can have anywhere from 50 to 200 different domains sharing the same server. That means 200 different users. If everybody has to have some of their folders and files set so anybody can write to them, what are the odds that sooner or later some script kiddie is going to hack the system and be able to get into everybody’s world-writable folders? This way the worst he can do is view or download the contents; he can’t change anything.

Susan, thanks for an excellent explanation. Very helpful and informative.

Quote from: sottwell at Jul 28, 2005, 01:37 PM

This way the worst he can do is view or download the contents; he can’t change anything.

A little further clarification, the files only have to be readable by the owner, so in fact, you can have all PHP files set to 500 or 600 and PHP works (nope, doesn’t have to even be executable to the owner). This would prevent those kiddies from even reading or downloading your scripts. On the other hand, if the group or world users have write access to scripts or a directory containing them, they will not execute at all. Added security against those that wish to harm our sites.

Ok, this is starting to make sense now!

Thanks

What affect does this have on modx and such self check installers?

Quote from: OpenGeek at Jul 28, 2005, 02:48 PM

Quote from: sottwell at Jul 28, 2005, 01:37 PM

This way the worst he can do is view or download the contents; he can’t change anything.?

A little further clarification, the files only have to be readable by the owner, so in fact, you can have all PHP files set to 500 or 600 and PHP works (nope, doesn’t have to even be executable to the owner).? This would prevent those kiddies from even reading or downloading your scripts.? On the other hand, if the group or world users have write access to scripts or a directory containing them, they will not execute at all.? Added security against those that wish to harm our sites.

but be sure that your directories are executable else you are not able to enter them