The problem have been discussed before (http://www.webhostingtalk.com/showthread.php?threadid=7847). A new solution have also been presented in that thread.

I think I have a partial solution to the problem. Users can still access other users files, but you won't need to hard-code any MySQL passwords in your files. The reason I'm presenting my solution here is that I think it is very easy to implement, no major configuration changes needed, and there will be no performance hits.

The solution is to use PHP's configurations directives to set a default MySQL username and password for each user, by placeing the directives in the users VirtualHost entry in httpd.conf.

Your httpd.conf must not be readable by the Apache user (or any user for that matter, except root.)

This way, of course, you will not be able to give your users multiple MySQL user accounts, but you can always give them multiple databases with the same user.

It is not a complete solution, but it solves a very seriouse problem in most shared hosting configurations. Besides, there is no real reason to refuse this solution, is there? :D

So what do you think?

That thread is so huge, that it's hard to see what information is useful or not.

My solution is this. (It might've been introduced in the thread but I got no time to read it)

Create users their own group, and put the apache username in their group. After that you remove 'read' from others.

If anyone is going to respond please make it short. I don't think people want to read pages about arguments who's right or not.

Hi Shyne,

I understand that, that thread has been going up and down for a long time now.

The solution you presented was discussed in that thread before, but there is one problem in it. Users can write PHP scripts that can do anything the Apache user and group can do (including listing other users directories and reading there files).

I've been bringing this example a lot, most people forget about it in their solutions:


<?php
include '/home/otheruser/public_html/forum/admin/config.php';
mysql_connect($servername, $dbusername, $dbpassword);
mysql_query('DROP DATABASE '.$dbname);
?>

This has been always a problem, but there are some work arounds.

#1 solution

1.) create two mysql db users (one with full rights, one with read only)
2.) install php as a cgi (keep the original php apache module as well :D)
3.) for example, if you have member sign-up = use the cgi version thru suExec or cgiwrap
4.) for all other operations where you do not need to INSERT data into mysql db, use the standard php code (not cgi version)..
5.) btw, setup the file permissions owner+read+write+execute for all php cgi based scripts to be safe (because you will have full access user password there)


#2 solution
If you have spare IP address, a bit of CPU and memory, plus a root access to the server you can do the following:

1.) compile apache+php support in a different directory (/apache2)
2.) create user secure, group secure
3.) chown secure.secure /apache2
4.) chmod o-rwx /apache2
5.) configure server port to be 8000 for example
6.) set-up additional IP for the server
7.) setup ipchains/iptables to do port forwarding from the extra ip address port 80 to port 8000
8.) block 8000 port


there you go - now you have a full apache server running for your project!


I hope this helps a little.

Ahmad,

If you add the users to the apache group, you can remove read from the group options.

I think PHP should take matter in their own hands and fix this. Maybe a way to encrypt the file?

Originally posted by Shyne
I think PHP should take matter in their own hands and fix this. Maybe a way to encrypt the file?


There are already ways todo php encoding....

And why should PHP do this? This is something known on in Perl too, but do you think they are gonna do anything about it soon???

Apache 2 is curing alot of these headaches... As this isn't a PHP problems, its how linux and apache does things...

Apache2 runs as the user, so the group permission is no longer needed...

Ahmad Slam,,

How a bout encoding the php script ?

using ZendEncoder or PHPGuardian

---------

The Only Little Proplem is:

THEY ARE VERY EXPENSIVE

zendEnconder is about 2000$
PHPGuardian is 300$

Originally posted by The Prohacker


There are already ways todo php encoding....

And why should PHP do this? This is something known on in Perl too, but do you think they are gonna do anything about it soon???


will..
for perl u encrypt eny script from the command line

just type:

man perlcc


NAME
perlcc - generate executables from Perl programs

DESCRIPTION
perlcc creates standalone executables from Perl programs,
using the code generators provided by the the B manpage
module. At present, you may either create executable Perl
bytecode, using the "-B" option, or generate and compile C
files using the standard and 'optimised' C backends.

The code generated in this way is not guaranteed to work.
The whole codegen suite ("perlcc" included) should be con-
sidered very experimental. Use for production purposes is
strongly discouraged.

Originally posted by Shyne
Ahmad,

If you add the users to the apache group, you can remove read from the group options.

Anybody can do anything Apache can do using PHP. This includes reading other users files. Apache must be able to read PHP files in order to be able to parse them, unless you run PHP as CGI, which is something most hosts aren't doing.

Originally posted by The Prohacker



There are already ways todo php encoding....

And why should PHP do this? This is something known on in Perl too, but do you think they are gonna do anything about it soon???

Apache 2 is curing alot of these headaches... As this isn't a PHP problems, its how linux and apache does things...

Apache2 runs as the user, so the group permission is no longer needed...

I fully agree.

The Apache 2 solution seems nice. Though I haven't looked into it, but from my understanding there is a performance problem in it.

The problem is, if you are going to use Apache this way, then you can't have one process for two different users. Because a linux process must run as a certain user. So in a shared environment, apache won't be able to use threading, it must fork a new thread for each visit (or at least for each visit to a file belonging to a distinct user on the system).

Originally posted by Shyne
I think PHP should take matter in their own hands and fix this. Maybe a way to encrypt the file?

Originally posted by Al Nadeem
Ahmad Slam,,

How a bout encoding the php script ?

using ZendEncoder or PHPGuardian

---------

The Only Little Proplem is:

THEY ARE VERY EXPENSIVE

zendEnconder is about 2000$
PHPGuardian is 300$


Originally posted by Al Nadeem


will..
for perl u encrypt eny script from the command line

just type:

man perlcc

[snip]



wa3alaykom al salam wa ra7mat Allah wa barakatoh ..

Lets take the perl example, if you compile a perl file to binary code, then can't you include it or "use" it in another file as a module?

If you can and you will have all the global scope available to that "use"ing script, then there is no point. I'm not exatly sure how Perl compiling works, but I will give you example in Python:


# compiled.py
secret = '$ecretW0rd'



# hacker.py
import compiled

print compiled.secret


even if you compile "compiled.py" into "compiled.pyc" and remove the .py file, anybody can include the compiled file legally and get all its variables.

This also applies applies to C/C++/Java and all other compiled languages. The compiler compiles the code but not the literal constants.

I've been thinking about encryption for a long long time, but I can't see any encryption scheme that will work in this context.

What does Apache2 has to offer to fix this problem?

I haven't checked the documentation for it yet, but I heared that Apache 2 can run as the owner of the file for all files, not just for CGI files, like in suEXEC.

Maybe the safe mode from php will help with this problem.

Originally posted by Ahmad
Anybody can do anything Apache can do using PHP. This includes reading other users files. Apache must be able to read PHP files in order to be able to parse them, unless you run PHP as CGI, which is something most hosts aren't doing.

If PHP is the main worry here, why not just add:

php_admin_value open_basedir ./:/home/user/:/tmp/

to each virtual host configuration in httpd.conf? You don't even have to have safe mode enabled for that to work. With the open_basedir directive in place user will not be able to include, fopen or unlink files that are not under their own userdir.

./

Why also that one? Because then they will be able again to enter: /home/user2/ or am I incorrect?

Originally posted by taivu


If PHP is the main worry here, why not just add:

php_admin_value open_basedir ./:/home/user/:/tmp/

to each virtual host configuration in httpd.conf? You don't even have to have safe mode enabled for that to work. With the open_basedir directive in place user will not be able to include, fopen or unlink files that are not under their own userdir.

Still, he can get the password using CGI (unless you are using suEXEC) or SSI (unless you have it disabled) ..

Besides, using safe_mode or the open_dir options will break many scripts.

Apache2 solves the problem because it uses threads AND processes. So, a seperate process is made per user, and each of those processes has multiple threads to handle the requests. From what I gather it is similar to running multiple copies of apache as different users, but 10X easier and automatic. Plus, making threads is cheaper than making processes, and if some one does something which would normally crash apache for everyone, it will only crash their own process running as them.