| Posted by digiacom, 05-26-2013, 11:44 AM | | I am having some challenges with wordpress on my reseller hosting.
When I install (Either manually or via Softaculous) Wordpress, I need to:
* set permissions of wp-content/uploads to 777
* manually update .htaccess for permalinks/plugins
* FTP login to install plugins/themes
Additionally, my premium Headway theme mysteriously doesn't work in some minor but annoying ways (only on this host), and W3 Total Cache constantly throws errors due to permission problems - it just doesn't really work, but all my client sites use it.
I could maybe cope with the FTP requirements since I can set the host, username, and password in the configuration files, but these problems are starting to drive me crazy - Simple Wordpress websites with headway themes are the heart of what I do, and it just isn't working smoothly. My clients would be flustered and lost in minutes trying to deal with this.
I've been contacting support constantly; They are very good at solving isolated problems, but laconic about fixing the underlying issue. When I finally asked if the state of wordpress on their servers is permanent, they said:
The website he referred me to has no workaround I haven't already found or can't implement without root, and hasn't solved my problem of having wordpress installations that would frankly confuse and frustrate my clients without my regular support. They said they enabled suPHP in litespeed to solve things, but it didn't seem to make a single difference in my experience.
I feel like my concerns are being swept under the rug, and I'm being told that an unusual permissions/configuration situation is normal and that I should accept it. Am I in the wrong? I've never needed to workaround so much to use wordpress properly before. I understand security is important, but needing to set '777' all the time seems like a bigger issue than making wordpress work smoothly in the first place.
What can I do?
(ps. I found the same/similar problem in a few other threads, I posted a new discussion to avoid hijacking/ressurecting an old thread since my situation feels different enough)
Last edited by digiacom; 05-26-2013 at 11:46 AM.
Reason: elaborating
|
| Posted by brianoz, 05-26-2013, 12:27 PM | | Unfortunately these guys are running PHP in a way that allows other accounts permission to access your files, and is a well-known security weakness. Not being able to access your site files means the webserver is running PHP in DSO mode - much faster, but too insecure to be workable on a shared user platform. Shared hosts generally don't run Apache in DOS mode these days.
Mode 777 is a recipe for disaster too - it not only allows others to access (read) your files, they can also now alter and remove them.
Without knowing more of the context, it appears this host doesn't understand security sufficiently well and perhaps you might be better off elsewhere? (In fairness there are some complex tradeoffs here, but the ability for web users to access each other's accounts is considered far more serious than the inability to change their own files, for obvious reasons)
To make Wordpress able to install and update you should be able to create an ftp accounts and use those details in WP settings.
|
| Posted by digiacom, 05-26-2013, 12:54 PM | | brianoz - I already feel more relaxed reading your response. Maybe they should hire you
My company is newer and I feel ready to bear with them as long as they can commit to solving these problems and learning what they need to do. It is a Litespeed server, they say suPHP is enabled whatever that means; I just don't know how to persuade them that the way it is currently set up isn't good enough for clients given how important wordpress (and scripts in general) functioning smoothly really is.
If they take this hardline against making it work better I might have to follow your advice and restart my host search
|
| Posted by digiacom, 05-26-2013, 07:03 PM | | Are there any steps or documentation for Litespeed that can alleviate the 777 problem? I am worried that if I change a client's permissions to 777 they won't remember to change it back, or will choose not to for convenience, and then the problem just gets worse and worse.
I will direct my host to this thread in my support ticket. I just don't know what else to do.
|
| Posted by foobic, 05-26-2013, 11:08 PM | | TBH I wonder if it actually means they don't know what they're talking about. On Litespeed they should be running PHP through LSAPI, which can configured "suexec" (setuid) or not. If you still need to set 777 permissions to allow PHP applications to write files then apparently it's not.
You can verify the PHP user for yourself easily enough. If they let you run PHP exec try this (in a PHP page):
Or if not just open up the permissions as much as necessary (temporarily) and let PHP write a file, then check the owner in shell or ftp.
|
| Posted by digiacom, 05-27-2013, 02:05 AM | | I ran the whoami command and it came up blank; I suppose that the shell_exec command wasn't able to run.
I'm going to recontact support. My host has been very responsive except when it comes to this issue, which to me feels like a very important one.
Thanks for the good advice.
@brianoz thanks also for offering a hosts perspective on the tradeoffs between security and convenience. I am trying to understand what security is compromised in the case of allowing PHP to execute in a jailed shell versus having clients with 777 permissions peppering their accounts.
|
| Posted by foobic, 05-27-2013, 02:46 AM | | Apart from the convenience aspect (obviously it's convenient to have PHP running as the user so no special permissions are required), the security tradeoff really comes down to where you see the greater risk:
An attacker hacking into your website directly, orAn attack coming from some other user on the same machine (including an attacker who's already broken into the other user's account)
Running setuid gives you minimal protection against the first case. If you install an insecure Wordpress plugin then an attacker gets full control of your account - in effect he is you. Whereas with PHP running as a different user, all those inconvenient special file permissions can actually give you some degree of protection (provided you also disable scripts in the directories where file uploads are permitted).
But in the second case, setuid protects you. Without it there's a bridge from the other user's account to yours, which the malicious user can potentially use to attack you. On a reseller server, if you're reasonably confident about keeping your own applications secure, this is usually the one you'd be more concerned about because there are a lot of other users on the machine and some of them are probably less careful.
|
| Posted by first2know, 05-27-2013, 01:43 PM | | Any situation in which you end up with filemode 777 is completely unacceptable if you ask me.
The security model on a unix system is based around users, and the moment you have something 777 - especially if it is later about to be executed as an install script - means that things that aren't real security flaws could be turned against you.
If you have a situation where many users need to upload files to their respective sites and allow the web server to write to it, I'd say one safer way to do it is to set the group of your directories to be that of the web server process, possibly www-data, and make the permissions 775 or 770.
It is normal in general to not allow the kind of writes wordpress expects - WP design goes very strongly against unix traditions - so I think you may need to find a host that explictly allows it if you want wordpress auto updates and plugin install to work.
Best of luck!
|
| Posted by brianoz, 05-28-2013, 07:21 AM | | Chris, very apt distillation of the discussion; and to respond to your summary: in general, hosting companies have almost universally settled on option (2) as the greater risk.
Why?
On a shared server, option (1) affects a single user, whereas option (2) affects potentially hundreds of users, and there's the crucial key point.
To extend this further, if you've been careless enough to let your site software get out of date and your site then gets hacked, fair enough that it affects you. It's not so fair, and affects many others, if your account can then be used to hack hundreds (and thousands on many over-oversold servers) of other accounts. Having hundreds of accounts compromised presents a very real commercial problem for a hoster, as they then have IPs getting listed on RBLs and upset hacked customers to deal with. 100 hacked customers can end up as many late nights and phone calls, or simply going out of business - or for a very small company, getting sick and disappearing. The key difference between option (1) and option (2) is the sheer number of users involved.
The idea is to use something like suphp (and the many other similar options) that partitions users into their own account. They then only have access to their own accounts, and filesystem permissions act as another barrier stopping them seeing files owned by other users.
The recent symlink problem was particularly nasty as it allowed a user, even though running under their own userid, to read config files from other users on the server. This ability is always there when the users don't run under separate userids - very painful stuff because essentially the system is wide open to all; and hence my point that it's a very, very bad way to go.
All of the above is very much true only for shared servers. On a non-shared server, say a VPS or dedicated server with one or two closely related and usually higher volume sites, the safest way to go is to run the webserver as one user, and have the files owned by another user. That way it's impossible to overwrite the site's logic and thus much safer. Since there are no other sites on the VPS/dedicated server, this makes more sense. Sometimes the difference here between what is good for shared versus what is good for dedicated confuses people.
The additional point for VPS/dedicated servers is that the faster Apache modes historically have been those that don't use setuid, and they also allow the use of PHP caches and precompilers such as APC. It's tempting to use these modes on a shared server because they're so darn fast, but it's a mistake as the risk is so high (and grows with number of accounts). If you want speed on a shared server, there are other safer options (such as nginx frontend etc). Of course, on a VPS these rules don't apply and you get to use APC and benefit from the speed very nicely!
Just my thoughts, perhaps someone else has something to share?
Last edited by brianoz; 05-28-2013 at 07:25 AM.
|
| Posted by bune, 05-28-2013, 09:06 PM | | Ask hosting to set PHP as suphp
This would help in keeping application with secure permissions of 755
|
| Posted by Kailash12, 05-29-2013, 01:15 AM | | If they have suPHP, you do not require 777 permissions for upload directory. 755 should work without any problem. Please note 777 permissions is not secured.. specially on shared hosting servers...
|
| Posted by digiacom, 06-01-2013, 12:17 AM | | Thank you guys so much for the help. I contacted management and they were very helpful. The problem persisted at first, so I recorded the problem and sent them a screencast of it (screenr.com - I am impressed at how useful it is). They had it fixed very soon after that.
A few lingering issues are lurking around, but overall I feel very well supported I referred the host to this thread and I think all your advice was pertinent and helpful. Thanks!!
|
|
 Add to Favourites
 Print this Article
|
