mkhost.co.uk Posted December 28, 2007 Share Posted December 28, 2007 why cant i see into my panel? http://uploadpicz.com/images/692IG5H.jpg 0 Quote Link to comment Share on other sites More sharing options...
mkhost.co.uk Posted December 28, 2007 Author Share Posted December 28, 2007 Critical Error CURL is not installed or is disabled on your server and it is required for WHMCS to run curl kind of uninstalled itself? 0 Quote Link to comment Share on other sites More sharing options...
Jay Posted December 28, 2007 Share Posted December 28, 2007 Did you update apache or something? Looks like you'll have to update apache with cURL. 0 Quote Link to comment Share on other sites More sharing options...
mkhost.co.uk Posted December 28, 2007 Author Share Posted December 28, 2007 Did you update apache or something? Looks like you'll have to update apache with cURL. alright. do i use /scripts/easyapache? 0 Quote Link to comment Share on other sites More sharing options...
arhost Posted December 28, 2007 Share Posted December 28, 2007 Make sure that your templates directory is CHMOD to 777. 0 Quote Link to comment Share on other sites More sharing options...
mkhost.co.uk Posted December 28, 2007 Author Share Posted December 28, 2007 Make sure that your templates directory is CHMOD to 777. Yeah, its chmod to 777 0 Quote Link to comment Share on other sites More sharing options...
hobbit666 Posted December 28, 2007 Share Posted December 28, 2007 what about the templates_c is that 777? 0 Quote Link to comment Share on other sites More sharing options...
Jay Posted December 28, 2007 Share Posted December 28, 2007 alright. do i use /scripts/easyapache? What control panel do you use? If it's cpanel then check in WHM. I had this same problem before and it just required an update to apache in WHM, just had to tick both cURL options. 0 Quote Link to comment Share on other sites More sharing options...
Jay Posted December 28, 2007 Share Posted December 28, 2007 Make sure that your templates directory is CHMOD to 777. That's completely unrelated as this is the admin area and those templates are for the client area. 0 Quote Link to comment Share on other sites More sharing options...
bear Posted December 28, 2007 Share Posted December 28, 2007 Make sure that your templates directory is CHMOD to 777. This is incorrect. From the manual: CHMOD the following folders & files: /configuration.php 777 <- after install 644 /announcements.xml 777 /attachments 777 /downloads 777 /templates_c 777 0 Quote Link to comment Share on other sites More sharing options...
arhost Posted December 28, 2007 Share Posted December 28, 2007 Sorry I meant: /templates_c If I chmod my templates_c folder other then 777 ,the admin area does not load correctly. 0 Quote Link to comment Share on other sites More sharing options...
mkhost.co.uk Posted December 28, 2007 Author Share Posted December 28, 2007 !! Critical Error (VZ): You are only only allowed to use 48 Megabytes of ram! 256 Megabytes is required. !! I get this once I upgrade. 0 Quote Link to comment Share on other sites More sharing options...
mkhost.co.uk Posted December 29, 2007 Author Share Posted December 29, 2007 Alright, I have fixed this. I needed more ram, so the company gave me 512mb ontop of what I've got. 0 Quote Link to comment Share on other sites More sharing options...
hobbit666 Posted December 30, 2007 Share Posted December 30, 2007 Sorry I meant: /templates_c If I chmod my templates_c folder other then 777 ,the admin area does not load correctly. In the manual it does say that the folder needs to be writable. I'm would say that when you load the site it places a file in there to give you the view, hence it needed to be 777. If the site can't write to it you don't get a page 0 Quote Link to comment Share on other sites More sharing options...
Jay Posted December 30, 2007 Share Posted December 30, 2007 In the manual it does say that the folder needs to be writable. I'm would say that when you load the site it places a file in there to give you the view, hence it needed to be 777. If the site can't write to it you don't get a page Arhost corrected his post and said templates_c, so not arguing there but it still had no relation to the actual problem that mkhost experienced. 0 Quote Link to comment Share on other sites More sharing options...
brianoz Posted January 9, 2008 Share Posted January 9, 2008 Re the mode 777 permission change recommended above - mode 777 is only relevant if you are NOT using suphp/phpsuexec. If you are using suphp, the mode 777 permission changes can be omitted as the directories are already writable to PHP scripts. This isn't made clear enough, nor is the following point, in WHMCS doco. If you are not using suphp on the server running your billing system, you are certifiably insane as your entire billing database is readable to every other user on your server. I am not making this up! (of course, you can keep everyone else off your server, but few people do that, and even then you can't guarantee that nobody will break into another user on the server). WHMCS really should issue a warning for accounts not using suphp (ie running as nobody, or running as a module). 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 9, 2008 Share Posted January 9, 2008 If you are not using suphp on the server running your billing system, you are certifiably insane as your entire billing database is readable to every other user on your server. How is executing PHP related to database permissions? SuPHP means that the scripts are run by the owner instead of nobody or Apache. Please explain. 0 Quote Link to comment Share on other sites More sharing options...
brianoz Posted January 9, 2008 Share Posted January 9, 2008 How is executing PHP related to database permissions? SuPHP means that the scripts are run by the owner instead of nobody or Apache. Please explain.I suppose that's a good question and probably why most people don't understand this ... The risk is that, without suPHP, all accounts run PHP as the same user 'nobody'. That means that if another user on the server knows the path to your files(*), they can read your raw PHP files and find their way to your database passwords. Once they have your database passwords they can read and modify your billing database, and if you've used the same password for cpanel they can also login to that. Also if you have folders that are mode 777 they can place any files they like in there, or remove files that are there. This is not well known to mortals but is very well known in the hacker community. (*) URLs and thus filenames are easily derivable from the visible URLs they see from moving through your site, or knowing the structure of WHMCS from another site ... 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 9, 2008 Share Posted January 9, 2008 I believe you are mistaken. A properly configured server doesn't allow you to "cross read" files elsewhere on the server (or things would get very interesting very quickly). SuPHP doesn't prevent this either. Things such as open_basedir and safe mode typically prevent directory traversal. 0 Quote Link to comment Share on other sites More sharing options...
brianoz Posted January 9, 2008 Share Posted January 9, 2008 A properly configured server doesn't allow you to "cross read" files elsewhere on the server ... In the past PHP restrictions such as open_basedir and safe mode were easily bypassed by knowledgeable hackers; I don't know the details, just that it's well known in the security community that they were trivially broken. I'm not sure of the situation with PHP5, it may have improved substantially, but I'm not assuming anything until I know for sure. Good security is built on layers, that preferably aren't obstructive. Suhosin and friends have other problems (that I'm not familiar with). SuPHP doesn't prevent this either.It does. With SuPHP, you simply don't have permission to read the "cross read" files, so there is pretty solid security enforced at the OS and file system level. This is done at the public_html level, which allows access to the nobody user (for HTML files, still read as nobody) and the account owner (for PHP files) (owned by the account user, in group nobody, with permission 750). SuPHP does present a performance load if you have a lot of load from PHP but on the average server it doesn't affect life much. Again, a lot of people don't get this point, so you're not alone! I've heard of countless exploited servers using this (eg on WHT, etc) - essentially a whole server can get "owned" if they have enough time on it - and the level of automation of their tools grows on a daily basis, so it doesn't take as long as it used to. 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 9, 2008 Share Posted January 9, 2008 This is done at the public_html level, which allows access to the nobody user (for HTML files, still read as nobody) and the account owner (for PHP files) (owned by the account user, in group nobody, with permission 750). I assume you've actually tried to publicly access a PHP file with those permissions? (hint: 0 for world means I can't read it from the web). 0 Quote Link to comment Share on other sites More sharing options...
JofleyUK Posted January 10, 2008 Share Posted January 10, 2008 ?? after all of this babbling..LOL... did the original problem get fixed! 0 Quote Link to comment Share on other sites More sharing options...
brianoz Posted January 10, 2008 Share Posted January 10, 2008 I assume you've actually tried to publicly access a PHP file with those permissions? (hint: 0 for world means I can't read it from the web). No, 0 for world only means that "world" can't read it, and since the public_html folder is in group nobody, web access is allowed through the group membership. Run a ls -ld command on a public_html folder and you'll see what I mean ... sorry if I was unclear! drwxr-x--- 3 <user> nobody 4096 Jan 10 18:40 public_html// 0 Quote Link to comment Share on other sites More sharing options...
bear Posted January 10, 2008 Share Posted January 10, 2008 No, I actually tried it. Did you? 644: Able to access and run. 750: Blank page, doesn't run. 0 Quote Link to comment Share on other sites More sharing options...
brianoz Posted January 11, 2008 Share Posted January 11, 2008 OK ... I think I've got you confused here by not being clear in my post above, apologies for that, just realized that now! The 750 refers to the *public_html* folder (as shown in my post!), *not* to a PHP file. The protection is enforced by the permissions on the public_html folder which has special group ownership and is mode 750, as in my last post. The actual PHP files, in a suPHP environment, can be 644, 750 or even 700, provided neither they nor the directory are writable (as tested) - they only need to be readable to owner. In a non-suPHP environment, the permissions must allow the PHP file to be readable to *other* (for the "nobody" user) hence what you're seeing with your test. If you'd like a small proof-of-concept, send me a PM and I'd be happy to put up hard evidence to back up my empty words. :) 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.