I have been trying to figure out how I can protect the contents of a file while still maintaining utility for web page generation. I would like to have account information (but never charge card numbers) and maybe MySql passwords in an include file. Help me look for holes in the following thinking. I'm asking here first but may ask elsewhere later.

There appears to be two, sometimes conflicting, requirements:
1. external security (users from the Internet)
2. internal security (other users on the same server)

The problem
For a file that I own to be browsable it must be chmod to xx4 (at a minimum) since apache/php runs as a different user ( as nobody) and otherwise browsed-php can not read the file. However, a permission of xx4 also gives other shell users on the same server (e.g. virtual hosting) read permission. Adding restrictions to .htaccess (e.g. password protection or allow, deny) can block browser access but has no effect on shell access by other users.

The Approach
1. chmod the directory to xx1 to prevent inadvertent indexing by browsers and viewing by shell users.
2. Use .htaccess to block apache/php access not originating on the home domain.
3. Deny access to other shell users by changing owner/group to nobody/me and by setting permissions to xx0.

The Discussion

External and internal security
Give the directory holding the file to be protected the permission of xx1 and not xx4/xx5.
xx1 seems to effectively block browser and shell views of the directory (in case your index.xxx or .htaccess does not work) but still allows apache/php access to specific files. Note that although this permission-set blocks viewing by shell access it does not prevent shell copying if the file name is know.

External security
Use .htaccess to limit browser access to php include files. The following seems to work.

<Limit>
order deny,allow
deny from all
allow from thisdomain
</Limit>

("thisdomain" could be an IP)

It seems to block direct access to the include file regardless of the extension (there was a discussion recently about which extension to use, .php, .txt, .inc, etc) and seems to block access regardless of the permissions (may be os-install specific). It still provides access to a php script running from the same domain. Good. There may be some issues about the ability to fake the client domain name (Domain spoofing?) but the host IP can be used and may circumvent the problem. Your thoughts?


Internal Security
Deny access to other users on the same server. Make the owner of the include file (the one to be protected) "nobody". Make the group the same as your user name. Set the permissions to 770 or any xx0. This gives all permissions to you and apache/php but denies world access (other shell users). Without root you will have to make these changes through a browsed php script. If it were not for this permission-limitation a shell user could run the script from his/her command line or include it into his own script, thus seeing the contents or output. Such a shell effort will run as him/herself. Under xx0 conditions these efforts will not have access. Your thoughts?

What have I overlooked. Is this good enough to hide MySql passwords.

Projo

I think I see a hole involving the user "nobody" but I will wait to see if it is obvious. Even if I only manage to keep my information from being causually available, that will be an improvement. This is a matter of someone obtaining a competive edge with my scripts, but I would survive expossure. It is also a matter of privacy for my clients, not their finances. I'll check it out.
Projo

You're off to a good start.

A couple of comments:

- you don't need to configure your htaccess to allow php scripts to access the include files. PHP will read the include files directly from disk, not via http, so .htaccess restrictions will not get in the way of PHP scripts. So, a simple "deny from all" directive will do that job, and eliminate any concerns of spoofing.

- for include files which contain sensitive information, such as passwords, put the files outside of your document root. For example, if you document root is /home/me/mysite.com/htdocs, put your include files in /home/me/mysite.com/include. Now there is no valid URL to get to the include file. You php scripts can use a relative path to reach the include files, like this:

include ("../include/dbpasswords.inc");

- for you internal security, i would switch the group and owner of the files: make them owned by you and a member of the group the web server runs as (usually nobody). That way you still own the file and can make changes to it. Make the permissions 640 -- giving yourself read/write access to the file, and give the webserver read-only access. Otherwise other virtual hosts can potentially modify your include file.

- for the include directory, only you need to be able to list the contents of the directory, so I would make it 740, owned by you, belonging to the group the web server runs as. This gives you full access, the web server the ability to read files (but not the ability to list the contents of the directory), and everyone else no access.

Hope this helps :)
Doug

Great comments.

Concerning the owner/group assignments: My initial thoughts were that I'm stuck in the virtual-hosting world (no root access) and can't change the owner but can chage the group with apache/php. I was thinking of modifying an apache/php file but your comment points out I could just modify my file. I'll try this. Root access would be much nicer.

Concerning location: I currently store above public_html. I moved down to test the effects of .htaccess and this move predated the owner/group reassignment experment. Thanks for catching it.