Important Notice:
Two sections of this forum are available only to registered customers. In order to receive access to the Customer Forums and ResellerCentral Forums, you must first register on these forums or login to your existing forum account. If you are an existing HostNine customer, be sure to register using the email address on file for your billing profile.
|
|||||||
![]() |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
|
Hi to all,
First i must say i have no complaints so far about H9. Also this is not a "revolution" thread, but simple my opinion about one thing with H9. Fact: H9 runs php as a module of Apache. With this setup every file uploaded will have a UID 99 instead of the user UID, because Apache runs with UID 99 (nobody). With this setup, when we need to write into a dir or file using a script on our browser we have to change permissions so that files are 666 and dirs 777 (for those that don't know, linux permissions are based on 3 rights for 3 groups on files and 4 rights in 3 groups for dirs: For files we have read, write and execute for groups Owner, Group and World = everybody). Leaving files and dirs in that state allows the whole world to acccess them. Also with this setup the H9 support has to go in and change permissions anytime a user needs to modify one of those uploaded files. So, with this setup we give more work for H9 support, security problems and files in our client area that we can't touch because they belong to UID 99! Since in order to execute a PHP file, it needs to be world readable the problem is that this allows every other users 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. This can be solved with phpsuexec!! PHPsuexec executes PHP scripts under your username. As such, instead of using everyone's permissions it uses the owner's permissions. You can thus change the permissions of your PHP scripts to : 0700 or 0400 and still be able to read and execute them. However, these scripts will no longer be accessible to any other users. In fact, PHPsuexec will refuse to execute a script if it is world-writtable to protect you from someone abusing one of your scripts. With PHP running as CGI with suexec enabled your php scripts now execute under your user/group level. Files or directories that you require your php scripts to write to no longer need to have 777 permissions. In fact, having 777 permissions on your scripts or the directories they reside in will not run and will instead cause a 500 internal server error when attempting to execute them to protect you from someone abusing your scripts. Your scripts and directories can have a maximum of 755 permissions (read/write/execute by you, read/execute by everyone else). PHP running as CGI/suexec is much more secure than the older Apache module method. Is H9 open to such change? I think it would benefit clients and support and leave everything more secure. Would love to hear your opinions and H9 opinion on this. Cheers, Santo |
|
#2
|
|||
|
|||
|
Well this is something we have been working with and testing but there are huge changes when it comes to PHPSuexec and PHP5. The other thing is there is still permissions issues with Suexec as you said they need to be different.
It's more common and standard to see hosts not running Suexec so users are more custom to it and once they get in to a Suexec environment it causes issues with their existing scripts. It also has it's fair share of security risks and both systems are neck and neck. At the end the main difference is for the CMS users that install moduels on the web etc. Since we use open_basedir protection, mod_security, and other various security on our servers the only issue we/ve had with running a non-Suexec environment is the Joomla ownership fixes. |
|
#3
|
|||
|
|||
|
Hi Ben,
Mainly you raise some valid points, but one remains as a big issue: Permissions. Its not only Joomla systems that are affected by it. Any script that runs in the Apache space and creates files (upload scripts, news scripts, and so on) will have problems with this setup, making you guys running around changing permissions. Anyway, i am priveleged to use 2 different hosts and 2 different setups. My preference goes for phpsuexec. No hassle with permissions, no need to go around giving 777 permission so the script can write to directories or create cache files and so on... My experience is very satisfying with suexec and CGI as module. Cheers, Santo |
|
#4
|
|||
|
|||
|
Santo,
A workaround for many files installed by the application is after the install FTP the files to your local that have "nobody" as the owner. Delete the file on the server. FTP your local copy back and it now will inherit ownership of the account user. This works for many...some will not delete... For these make a jail directory FTP to your local Move them to the jail directory FTP your local copy back to the correct location Still leaves a few files that resist the above two methods Once an install is up running and functional(in business and not a development site) changes are minimal. At this time you can request that jailed files be removed and the stragler files that you could not change can be chown'ed through a service resuest. Small price to endure and should be most prevalent only during development and or when a major facelift is in the works. |
|
#5
|
|||
|
|||
|
Hi Kobra,
The problem gets worst with scripts like photo galleries for example, where the users upload hundreds of files, and when you check them... they all belong to "nobody" instead of your user ID. The Joomla example is only one among multiple cases where this is true. And you are right, as most systems only need this tweaking on system setup, but many more exist that will cause problems. Anyway, this is just an idea. I will have to split my clients based on what they want to run (script wise), so my support calls don't increase due to permissions and stuff like that! Cheers, |
|
#6
|
|||
|
|||
|
Any news from H9 on whether they plan to implement phpsuexec?
I've just installed Joomla and am worried about having to grant write access to public just to be able to install components and allow Joomla caching etc. I'm not sure what the risks are but granting write access to everyone just makes me uneasy! |
|
#7
|
|||
|
|||
|
We already have phpsuexec in Reseller Central and on some reseller servers. We're still thinking of how to upgrade existing servers without causing major issues for everyone.
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Changes to Security Question Setup | H9NickH | General Announcements | 0 | 02-21-2010 07:59 PM |
| PCI Compliance/Security | idesign | Feedback & Suggestions | 7 | 05-04-2009 03:17 AM |
| In My Opinion.... H9 is..... | Chris | Customer Testimonials | 1 | 07-07-2008 12:57 AM |
| Please give an opinion | detoam | Reviews | 8 | 04-25-2008 03:13 AM |
| How about security? | beno | Pre-Sales Support | 3 | 11-23-2006 08:42 AM |





Linear Mode

