Hi, I searched for previous posts about this but found nothing that really answered it. I have just installed Modx for the first time and I like what I see, but I am concerned about the file permissions that were required to be changed to 777 during installation.
Am I missing something here? Leaving folders at 777 seems to be an invitation for nasty people to deposit all kinds of silly stuff there - spam scripts, shell scripts, you name it.
The same reasons that ModX tells you after you install that you should make the config.inc.php file read-only.
If there is some other form of protection that allows the 777 to be left there safely, great - but I’m not seeing it.
Should we change the ownership of these folders perhaps, or add an htaccess with ’deny from all’ in it?
Thanks.
Thanks for the reply.
So I take it this means the script is not ’officially’ secure unless the server uses phpsuexec (or suPHP which I’ve not heard of but sounds like it is a similar thing) ?
The thread you linked to has some suggestion that mod_security can be effective? Any idea how? My experience has been mod_sec is great for blocking sql injection etc, but can it be used to prevent uploads to a directory with 777 permissions?
Or any ideas whether htaccess ’deny from all’ is effective - I was lead to believe that can be used where the only access to a directory required is by other php scripts on the site. I’ve used it in other situations, and seems like it works, but I don’t know enough to be confident on that.
Thanks.
I have CGI/FastCGI in phpinfo, run my folders (default) in 755 and have register_globals turned off. That makes me feel pretty safe.
If you have dead important stuff make sure not to use shared hosting and htaccess is probably the way to go.
Take backup! That enables you, if hacked, to just vipe everything away and reupload clean instead of searching hiden scripts.
MODx revolution is a safer beast, where you can have the manager directory outside www...
Depending on the setup you can use 755. The main issue is that MODx needs to be able to write files (cache, uploads, etc..) if your server can allow that to happen without 777 than great, otherwise it will need to be 777. I agree that the installation requires to set more dirs to writable than are 100% needed (there are a umber of dirs that I don’t even think are used). Any CMS that supports a file browser will require a writable dir, and any application that has a file cache will also have this requirement.
Hopefully I’m not causing too much of a problem picking up an old post, but this has been something causing me a fair bit of grief recently on a shared account.
Firstly, I’m pretty sure my sites used to be fine with /images/ and /cache/ set to 755. However, after a couple of hacks and restoring these sites from back-ups, I’m getting an error from the manager about those directories not being writable (unless set to 777). I guess this might be to do with recent changes made to the server?
From what I can see in phpinfo the server isn’t running suExec, and I don’t think it’ll be an option. It looks like the host is not keen on 777 permissions after recent hacks (which is understandable), so the problem I have is, if I have to keep directories as 777 to ensure MODx still works, how can I tighten security - without suExec?
I know I could use htaccess, and for the /images/ directory it looks pretty straightforward to block anything but jpegs for example, but I’m a bit lost with /cache/ - as I guess php files need to be written to it.
Any suggestions would be hugely appreciated!
Maybe you can leave the folder at 777, add to htaccess ’deny from all’ and change the chown on the affected directories to ’apache’ (or whatever your web server is called if not apache). You will need SSH access to do the chown I think (or get your host to do it for you).
Dont know if this will work, but seems worth a try.
Cheers.
Thanks scapes. It looks like the host has made a change to the server - from the looks of phpinfo it’s now running as CGI (I think - a lot of this server admin stuff is still above my head!).
Anyway, things seem to be working fine now and directories can be set to 755 without any issues.
The only remaining problem (or perhaps resultant problem) is that the .htaccess file doesn’t seem to be working, as friendly URLs don’t ’work’, and neither does the rule to turn register_globals off.
Nearly there - hopefully the host will be able to explain the htaccess problem. Anyone had a similar issue?
