Thread

If ExpressionEngine can’t write to the necessary folders, then you may have difficulties in creating CAPTCHAs, uploading images, if your cache is set to less than 777 then you’ll have problems writing cache folders and files; so yes, it is a less than optimal environment for ExpressionEngine.

Lisa, setting a folder with 777 right now, is critically dangerous…

phpsuexec isn’t turned on by default… so is there anything I could do beside chmod cache directory to 777?

and I thought you can set them less than 777, as per Derek’s comment:

In these situations, you can leave permissions at 6xx for files and 7xx for directories and ExpressionEngine can still write to the files, because the script is running as you, the owner of the file.

Larry, this is really something that you need to take up with your host.  ExpressionEngine needs to be able to write to those directories; Derek, in the comment I linked you to earlier, mentioned a possible way to handle this; but your host should be capable of providing an environment that is both secure, and friendly to scripts that need to write information out.

If they are not able to do so, then you might wish to consider a host that can.

This was the comment from the web admin:

I am aware of this issue and what’s causing it, I’ve seen it before. The core of the problem is :
Not having phpsuexec installed on the server. But believe me if I suddenly switched over to phpsuexec many cusotmers would start screaming. The root issue here is that no directory should be chmodded 777 in the current server setup that we have. Also regardless of the software running on the server (php) - we allow ssh access to a number of clients. Do you realise that if any of your directories are chmodded 777 that any other ssh user can enter that directory and delete files from it? We are not about to stop offer ssh access, so even switching to phpsuexec will not prevent ssh users from having access. You will need to think about an alternative to chmoding a directory 777 - its never advisable.

Its not Jumba/AussieHQ’s fault. This kind of problem is the same for them and thousands of Web Hosts worldwide - that’s why Jumba recently switched over to phpsuxec - but they went through hell as a result. We’re not ready to take that step just yet, but will at some point soon.

Larry, there are many, many hosts that do not run PHPSuexec that do not have these security problems; using SSH as the excuse is pretty scary; users on a shared hosting server should never be able to access another user’s files, regardless of 777 permissions.

I would recommend finding a host that is more secure; I would not personally feel comfortable with a host that finds the current situation acceptable.

can expression engine run properly with phpsuexec turn on?

I am not even sure where to begin on that very lame answer from their server admin… not sure to laugh or cry at the though of people like that running servers.

Just a very small thing to think about. 

As it stands now, even if you don’t leave ANY files/folders in your account writable, they are all readable.  So that means any scripts you have with MySQL usernames/passwords in them are also readable.  MySQL privileges are based on a username/password and servers/ip address ranges that the username/password is allowed to be used from.  SO think about this, they now will have the same full privileges to the data in your database that you do.  Any content you have listed as “private” in a blog, or “intranet” application, client/project management tool. This would also be any data you promise to protect for your site visitors, if say they register with you, all of their email addresses for instance, or names/address/phone numbers/IM usernames, etc.  Anything and everything stored in your databases, and all other databases on that web hosts servers, are all available for anyone to use/access or even delete data.  Nice thought…

That is only one of many things that simply make me cringe when reading that answer from them… I have to bite my tongue on other things I want to say…

so what do you suggest other than enabling phpsuexec to secure this ?

Well if you running a secure hosting that can allow folder to be 777, here’s the question”:

how to setup a server to allow php scripts to run as user nobody and allowing chmoding of directories 777 - without ANY security vulnerabilities.

Well if you running a secure hosting that can allow folder to be 777, here’s the question”:

how to setup a server to allow php scripts to run as user nobody…

Don’t, as its not the proper way to run scripts, hence the problems you are seeing.  This is like asking how to securely lock up a car, if everyones car keys are the same.  But I am also not here to *teach* people how to run secure web servers, not actually my job I am afraid.

without ANY security vulnerabilities.

In a properly secured server, your own scripts, running in your own account, will always have the ability to affect things in your own account, so *ANY* is a strong statement. Nothing is 100%, but throwing your arms up and saying “well its common, so live with it”, is the wrong way to handle security.  Just because something is “common” does not mean its right, or the only, or proper way to do things.  The excuse just means people are complacent, unaware, or can’t be bothered to provide proper security to their hosting clients.

If this was so common then many more users in these forums would be suffering the same issues.  Being I can say for certain that not everyone in these forums is a hosting client of ours, I would say its not a very common issue, but is a good answer from a hosting company that does not want to seem to be bothered with putting proper security between their hosting clients accounts and scripts.

People in these forums will be happy to recommend hosting companies that they don’t suffer issues like this.  Just ask, or check out other threads asking about hosting companies.

Fair enough Nevin…

Thanks Nevin and Lisa, appreciated your help!

Come on, name and shame already… it will benefit the community 😊

I’m glad we were able to help draw some closure and clarity to this for you larry.  Nevin is the best in the business.  I’m going to close this thread now before specific names start being mentioned.  While we always want our customers to have access to knowledge, we have to walk that line, specifically when it comes to other hosts or recommendations.

If you have any further questions or concerns, just start up a new thread, and I promise you you’ll receive the same prompt and helpful response from us again.