Just when you start to think you actually get to know your way around Linux a question pops up that makes you feel like the nitwit that you really are :(

Received this email from a customer. I am open for suggestions!

I do have a question. I'm using cache files for my website. The first visitor will force a php function to start, which create cache files. The second and later visitors will see this cached files, which makes the access to my site quicker.
I do have a problem with the following: the cache files are written into the /cache subdirectory. So the 'apache user' must have access to 'execute' the directory and to write into it. For now, I must make the cache directory executable, writeable and readeable for the world to make this possible (chmod 777). But then of course, the whole world can write data into this directory.

Is there a way to block others to write/read/execute files in this directory, but grant it for the 'apache/php user'?

From what I understand the best way to handle this is to run apache with suexec. That way it will run as the user and you can set the security on the directory for just that user to have access.

If you are using Cpanel you could try running PHP as a CGI program and use the cgi wrapper utility that comes with Cpanel that will allow it to run as the user.

Richard

I did a quick lookup on suexec but the apache official docs keep warning to stay away from this if you do not know exactly what you are doing. I think they mean me :D

I assume password protecting the directory with .htaccess would not do the trick since people that really wanted to would still be able to use a script to go directly to the url without viewing the directory.

How about a .htaccess file that would only allow a program that is on the same server to that directory. Is that possible?

Ignore that warning on Apache site. Just do it as if there is no warning :)

Until Apache 2.0 is finalized, your only option as of now is to use suEXEC and run PHP as a CGI program. That way it will run under his userid and not the webserver's and he can set permissions accordingly.

However, even if he leaves it 777, I seriously doubt that anyone will mess with his files.

I have had this problem for long and I am with a host that uses the stupid cpanel (which I don't use or care for). I understand that suEXEC does not work well with cpanel or something like that. I Don't understand why so many hosts use it.

A simpler solution might be to have him write the files to /var/tmp. This way they are not anywhere in the web server root path. The program can access them, but no one from the outside can (of course anyone with a shell account on your server can also access them :().

Also, if the image on your site is any indication you are doing hosting on a RAQ. If you are, then you should already have CGIWrap installed -- which does basically the same thing as suEXEC.

You do indeed need to use SuExec, just try it out on a machine that's not in production.
Running PHP as CGI however is not necessary.
PHP has a feature called safe_mode, which will make sure that a php script owned by user X will not touch files that are owned by user Y and I think it also wouldn't let user X place files in a directory owned by user Y, but you'd have to double-check that.
The only disadvantage of safe_mode with PHP is that scripts using move or move_file (one of those two, not sure) to handle file uploading will have to change their scripts to use move_uploaded_file instead :)

Okay... good luck :)

PHP safemode won't help much if your users have access to shell account. The safest bet is to use suexec and PHP in CGI mode.

Thank you all for your input.

I'll try the suggestion of uulan first. Put the files in a world writable directory that is part of root instead of the website.

Mostly because I understand that method. Shell access is disabled so nobody will be able to see his files except us.

And for crying out loud...it's not creditcard data he is trying to hide ;)

Originally posted by Pilgrim

I'll try the suggestion of uulan first. Put the files in a world writable directory that is part of root instead of the website.


yay! I win :D

if apache runs as user nobody:nobody just chown the directory to that and chmod 700 it.. Only apache will be able to access it with full read write.

Originally posted by priyadi
PHP safemode won't help much if your users have access to shell account. The safest bet is to use suexec and PHP in CGI mode.

suexec has to be used indeed for ordinary cgi scripts. but PHP safemode might safe you from running PHP as CGI, which is a major performance hog.
But I'm not sure if running PHP in safemode also prevents user X from creating files in a directory owned by user Y.
If it does, than from a security point of view there is no benefit to run PHP as CGI over running it as a module in safe_mode.

Originally posted by zupanm
if apache runs as user nobody:nobody just chown the directory to that and chmod 700 it.. Only apache will be able to access it with full read write.

as can all the other users cgi scripts... :bawling:

Originally posted by T_E_O


suexec has to be used indeed for ordinary cgi scripts. but PHP safemode might safe you from running PHP as CGI, which is a major performance hog.
But I'm not sure if running PHP in safemode also prevents user X from creating files in a directory owned by user Y.
If it does, than from a security point of view there is no benefit to run PHP as CGI over running it as a module in safe_mode.

PHP safe mode is nowhere near flexible. For it to be secure, it must not be able to write to filesystem (as anything written will be owned by apache user, thus readable by almost everybody) and it should not be able to execute anything (as it will beat the purpose of safe mode in the first place). This requirement will break quite a lot of scripts out there, and can be a pain for you and your users.

With Apache module, you have a choice of inflexibity or insecurity, and you can't have neither :(. With CGI mode, it is as flexible as it gets, and it is secure. It is rather slow however, but people has been doing this with Perl for AGES, with much slower computers, and nobody ever complains, and even with today's technology like mod_perl, fastCGI or speedy, people still don't complain it they have to run it in CGI mode. Unless if you run a major big site, you won't need PHP as Apache module.

Originally posted by priyadi
Unless if you run a major big site, you won't need PHP as Apache module.

There are differences when PHP is running as CGI scripts that can break a lot of scripts out there too ;)

You can just chmod 777 or chown nobody:nobody either way other ppl can still get to each other's files.

To be 99.9% safe use a dedicated server or a virtual server

As pointed out, others won't bother about his files anyway... and if they do, time to do some kickin :)

I feel like I am a student in a classroom with 10 teachers in front of the class who are trying to teach me something.

Then in the middle of the explanation they start to argue amongst themselves and question each others solutions to the question the student asked.

10 Quarreling professors and one very confused student who watches them while they argue amongst themselves and thinks "how the hell did I get into this. Even more important...how do I get out?" :D

Just kidding. :) Thanks for the input.

Originally posted by muppie


There are differences when PHP is running as CGI scripts that can break a lot of scripts out there too ;)


I know some script can break under CGI mode (ones that uses apache specific functions), but not many of them. I have been running my biz with CGI mode PHP for years, and I haven't seen customer complaining their scripts won't run in CGI mode (apart from they must chmod +x their scripts). I have tested many major scripts out there, like PHPnuke, phpgroupware, postnuke, phpwebsite, phprojekt, and many others. They all run without problem.


You can just chmod 777 or chown nobody:nobody either way other ppl can still get to each other's files.


Not if PHP is running in CGI mode + suexec :)


As pointed out, others won't bother about his files anyway... and if they do, time to do some kickin :)
We had a thought about it too. But how can I tell if one user has done something with other user's files? More importantly, which user? I imagine it would be a very hard and time consuming question to answer. :)

Originally posted by priyadi

...

For it to be secure, it must not be able to write to filesystem (as anything written will be owned by apache user, thus readable by almost everybody) and it should not be able to execute anything (as it will beat the purpose of safe mode in the first place).

...


Ok, I surrender :D
I'm going to start a virtual server hosting biz anyways, not a shared hosting biz ;)

Priyadi,

if a site has about 60-80GB transfer a month, is it still wise to use php as cgi?

I'm just wondering I might give it a try on a non-production site and test all the incompatibilities out, if the real sites can use it as cgi.

Have you tried vbulletin / phpbb on php as cgi ?

thanks

Originally posted by muppie
Priyadi,

if a site has about 60-80GB transfer a month, is it still wise to use php as cgi?

I'm just wondering I might give it a try on a non-production site and test all the incompatibilities out, if the real sites can use it as cgi.

Have you tried vbulletin / phpbb on php as cgi ?

thanks

The bottlenick in these situations is usually the SQL server, so unless persistant connections are proving as a performance enhancement, there will be no big difference.

Apart from all that, a 60-80 GB transfer of PHP hits, should really be on a dedicated server ;)

Originally posted by muppie
Priyadi,

if a site has about 60-80GB transfer a month, is it still wise to use php as cgi?

I'm just wondering I might give it a try on a non-production site and test all the incompatibilities out, if the real sites can use it as cgi.

Have you tried vbulletin / phpbb on php as cgi ?

thanks

I have no experience myself with that kind of load. But 80 GB a month is quite a load, in my calculation, it is probably more than 100K hits in a day, that means more than one hit in a second on average. However, i think php as cgi itself will do fine with only less than to request in one second, assuming you have enough memory. It is the database that I'm worried about. If you have that kind of load, you must have a lot messages and users. And that needs quite a process for every hit. My guess is if your server can handle it with php module, it will probably do just fine with php in cgi mode, albeit a little slower, at most about 1 second slower. It will require more memory and CPU usage though.

vBulletin on a shared hosting account:


<?

include '/home/anotheruser/forum/admin/config.php';

mysql_connect( $servername, $dbusername, $dbpassword );
/* <<EDIT: the next line isn't needed>> */
mysql_select_db( $dbname );
mysql_query( 'DROP DATABASE '.$dbname );

?>


It seems like 'anotheruser's db is gone! :angry:
Too bad, it had 60-80 GB of hits :D

Originally posted by ahmadhash

It seems like 'anotheruser's db is gone! :angry:
Too bad, it had 60-80 GB of hits :D

LOL! A good one :)

btw, it is nice to see another person who shares the same view on this :) there are not too many of them :)

Originally posted by priyadi

btw, it is nice to see another person who shares the same view on this :) there are not too many of them :)

I can see what you mean ;)

&*&^*&% Some days you just want to pull your hair out :rolleyes:

Because one of my customers had problems I just downloaded and reviewed the server error log.

I immediatly noticed the words suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) appear many times.

Checking root it appears suEXEC is already installed. The date that it was installed was months before I even got the server (Rackshack) so my best guess is the previous owner installed it.

:rolleyes: :bawling: :rolleyes: :bawling: