www.turkiyespot.com web sayfası kontrol panelleleri yardımlaşma forumları

[turkiyespot]

Merhabalar,
Güvenlik ,güncelleme ve bakım sonrasında phpSUEXEC e geçmiş bulunmaktayız. Bazı sitelerde hata olacağını düşünerek aşağıda makaleyi yayınlıyoruz.
1-phpSUEXEC 777 olan klasör izinlerini kabul etmiyor 755 yapmalısınız.
2-phpSUEXEC htaccess dosyası içine yazılan komutları kabul etmemektedir, bunun yerine php.ini dosyası oluşturarak komutlarınızı buraya yazabilirsiniz.
örnek:
register_globals = off
register_argc_argv = off
safe_mode = on
magic_quotes_gpc = off


PHPSUEXEC - What do I need to know?
The security hole of PHP
On most Apache servers, PHP runs as an Apache Module. As such, it runs directly in the user Nobody, but doesn't require the execute flag. This means that in order to execute a PHP file, it simply needs to be world readable. The problem is that this allows every other user on the server to read your PHP files!
Allowing other users to read your HTML files is not a problem, since they can be displayed in Internet Explorer. However, PHP files are not readable, they are parsed. Many scripts use a PHP file to store a database username and password. This means that on another server every client could read your PHP files, retrieve your password and access your databases.
ISPs close this hole by installing an Apache module called PHPsuexec, which executes PHP scripts under your username. Instead of using everyone's permissions it uses the owner's permissions. Thus you can change the permissions of your PHP scripts to 0700 or 0400 and still read and execute them. However, these scripts will no longer be accessible to any other users -- PHPsuexec will refuse to execute a script if it is world-writable to protect you from someone abusing one of your scripts. All servers will be running PHPsuexec within the near future.
You can easily tell if your server has PHPsuexec enabled by visiting your server’s phpinfo page:http://your.servername.com/phpinfo.php/ simply look for the following near the top of that page. (4th Box Down Server API) :- “Server API Apache” This means that your server is currently running PHP as an apache module. If within the phpinfo page you see the following: “Server API CGI” Then your server has a CGI installation of PHP with suexec enabled.
What is the difference?
Most sites will not be affected with the change, running PHP as cgi with suexec. PHPsuexec works in much the same way that cgi (Perl scripts etc) with suexec does, all applications being run under your account user name UID/GID, rather than in PHP’s case as an apache module, the user “nobody”.
This simply means that rules that apply to .cgi + .pl files on your current server, apply to PHP files also. The maximum permissions permitted on directories and PHP files are 755. Failing to have permissions set to a maximum of 755 on PHP files and their installation paths, will result in a 500 internal server error, when attempting to execute them.
File & Folder Permissions
As you can see from the table, the only required permission is ‘owner-read’ 0400, but if you need to write to that file, you need to also enable the owner-write permission 0600. It is recommended that all your PHP files have chmod permission 0400 or 0600. The execute permission is never required, and the ‘group’ and ‘everyone’ permissions can be left to 0.
PHPsuexec also validates the directories in which PHP files are located. A PHP file cannot be executed in a directory that is ‘group-writable’ or ‘world-writable’. However, in order to access a directory, it must be ‘world-executable’, which is safe to do. So folders containing PHP files should have permissions 0755 or 0555.
Questions
777 - Do I need directories set to this? My install script says that I do.
No, you do not need to have directories or files set to 777, even if your installation documents tell you that you do. Permissions of 755 will work in the same way - Scripts owned by your account user UID/GID will be able to write to your files, the same way that they can running under apache with 777 permissions.
If you have PHP applications / scripts that have directories set to 777, (required to write to them under PHP/apache module), they would need to be changed. Also we would need to change ownerships of all files owned by user “nobody” to the user name UID/GID for your account.
.htaccess
You cannot manipulate the php.ini settings with .htaccess when running PHP as cgi/PHPsuexec. If you are using .htaccess with php_value entries within it, you would receive an internal server 500 error when attempting to access the scripts. This is because PHP is no longer running as an Apache module and Apache will not handle those directives any longer. All PHP values should be removed from your .htaccess files to avoid this issue. Placing a php.ini file in its place will solve this issue. (Please see below.)
Default settings, I need Zend Optimizer or PHP to run with different options than the servers default settings, can I do this?
The server default settings with php.ini may restrict certain applications, it is possible to modify the settings and how PHP will run on your account, on a per directory basis. If you have an application that requires for example :-register_globals = On Then by creating a file named php.ini within the directory that the script is located within, with the entry register_globals = On would allow you to run that script with your settings.
If you also require say Zend Optimizer to be installed for your application, you would have :
register_globals = on zend_optimizer.optimization_level=15 zend_extension = “/usr/local/Zend/lib/ZendOptimizer.so”
You may copy the other variables from the phpinfo page as they appear within it and modify the settings as required for your scripts.
Some important relevant default PHP values are as follows:
register_globals = off register_argc_argv = off safe_mode = on magic_quotes_gpc = off
All other settings can be viewed from your server’s phpinfo.php page.
Quick trouble shooter . . . . . HELP my PHP script doesn’t work or I have an error message
1 Check that the PHP script that you are attempting to execute has permissions of no more than 755 - 644 will work just fine normally, this is not something that will need to be changed in most cases.
2 Check that the chmod permissions for the folder that the script resides in are set to a maximum of 755. This also includes folders that the script would need to have access to also.
3 Check that the files are owned by you i.e. not owned by user ‘nobody’. Certain applications having been run under PHP as an Apache module, may have files owned by the Apache user - In that case, submit a helpdesk ticket for the file ownerships to be changed.
4 Check that you do not have an .htaccess file with php_values within it. They will cause a 500 internal server error, when attempting to execute the script. The php_values will need to be removed from your .htaccess file and a php.ini put in its place, containing the PHP directives as explained above.
More Information How to install suPHP:
http://www.phpasks.com/suphp/index.php








I can almost see you shaking and shuddering at the thought of doing this but it’s probably not as bad as you think. Armed with a little bit of information and a few commands, you should find the upgrade goes fairly smoothly. I’ve just upgraded 2 of my own dedicated servers and apart form a couple of minor glitches the whole process went fairly smoothly.
I’m going to assume that you have the latest WHM version installed (with EasyApache support), you know how to use SSH and that you have a fairly good idea of what you are doing.
First up, lets look at what you need to do to get Apache upgraded to use PHP5 and suPHP.
1. Login to WHM as root
2. Click on Software->Apache Update in the left hand column.
3. Click on “PHP Security”
5. Click on “Start Customizing Based On Profile” and enable th options you want compiled into PHP. I usually go to the “exhaustive options” step and set it up just the way I want it.
Once that’s all done you can start the build. It could take a little while (mine takes around 20 minutes) so go make a cup of coffee and wait for the update to complete.
After the re-build
This is where you would generally start to sweat a little, but fear not … there’s not all that much that can go wrong if you follow my instructions.
Your first problem is going to be that your upgraded Apache/PHP will throw a ‘500′ error if it finds any files or directories under public_html that are world writable. This is an easy fix. All you need to do is to change directory to public_html (e.g. cd /home/username/public_html) for each cpanel account and run the following commands:
find . -type d -perm 777 -print | xargs chmod 755
find . -type f -perm 777 -print | xargs chmod 644
find . -type f -perm 666 -print | xargs chmod 644
Those commands will change any world readable directories and files to 755 and 644.
The other main thing you need to be wary of is scripts that expect the PHP register_globals setting to be on. This is very very bad. You will be able to tell because your forms won’t be posting some or all of the field values and you may just find some script functions and links trhat simply don’t do anything any more. Fortunately there are fewer and fewer scripts around that have this requirement, but if you find that you do have a script that has this requirement, there are a couple of options.
1. Add this command to the top of any files that aren’t working:
ini_set(”register_globals”,”On”);
2. If you think there are too many files for step 1 you can edit your php.ini file and set the register_globals setting to ‘On’.
3. The recommended option – upgrade or replace the script. Register_globals opens some potential security exploits regardless of how you apply it, so if at all possible .. you should leave it set to ‘Off’.
I had one other error on the last server I updated. After setting the correct permissions I was getting a ‘404′ error. In the /etc/httpd/logs/error_log I could see the following error message several times:
(13)Permission denied: /home/*****/public_html/.htaccess pcfg_openfile
: unable to check htaccess file, ensure it is readable
The cause was right in front of me, but it took a while to work it out. At some point I must have accidentally changed the ownership of the public_html directory to username:username. The standard permissions are 750 which gives the owner write access and the group read access.
Now here’s the tricky part. Modules such as mod_rewrite that processes the .htaccess file are loaded in Apache and are global. So, instead of being executed as the account owner, they are executed as the default owner and group of Apache which is the ‘nobody’ user/group. Do you see the problem? Because only the owner and owner group have permissions, the user nobody does not even have read permissions to anything under public_html. When I looked at a few of the other accounts that were working okay, the ownership of the public_html directory was user and the group was nobody. So, as soon as I fixed the group , Apache was able to read the .htaccess file.
Those are the main issues you might see. Obviously you should also do your own search for things like ‘WHM suphp problem’ to find out if there are other things you need to be aware of, but for the majority of sites, the instructions I’ve given should go a long way toward a smooth upgrade.
After finishing this post, I found some excellent info at v-nessa.net. There’s a very complete guide to enabling suPHP which goes into settings and other options. I added an additional step the procedure I was using and that was to run the scripts:
/scripts/postsuexecinstall
/scripts/chownpublichtmls
..and another important step:
rm -f /temp/sess_*
This removes old session files that will more than likely be owned by ‘nobody’ and could cause problems for people who are using some of the sites on your server when you did the update.
What they do is tidy up some inconsistencies such as files with the wrong ownership. My most recent update, using the procedure mentioned above, involved a site that hosts around 150 CPanel accounts.

[www.turkiyespot.com ucuz hosting]

www.turkiyespot.com iyi Hosting vps vds radyo iyi reseller, kaliteli hosting, kaliteli host, kaliteli vps, iyi vps