[JDubya]

I know how to chmod files on a server via FTP but these are local files. I just installed WordPress and an e-commerce theme on a localhost via MAMP. However, when I activated the theme, it said I need to adjust the writing permissions to chmod 0777 of a few folders (bills, dl, uploads, and cache). I've seen a few different Terminal command lines recommended to chmod but I'm not well-versed in Terminal and I don't want to screw anything up. What do I need to do? (I'm running OS X 10.7.2) Thanks

[Waragainstsleep]

I think its just

chmod /pathtofileorfolder 777

[besson3c]

chmod -R /pathtofolder 777

but *only* do this on your local machine. Do *not* do this on a server, because this makes the directory writeable by literally anybody regardless of whether they have access to your account, and puts your site at all sorts of risk. I've seen IRC bots talking to servers in Russia being run from directories set to chmod 777, it is actually pretty easy to do this if you enable world writeable access to a directory. Not only does 777 make the directory world writeable, but also world executable needed for running literally any application. This could get your site shut down and/or blacklisted.

If you need to make a directory writeable by WordPress on the server, find out what username the web server runs as, and do a:

sudo chown -R <webserveruser> /path/to/directory

if this is a shared host where you do not have root access necessary to run the above command, contact support. Do *not* just chmod 777 the directory, this is a very bad idea.

Sorry, I'm just trying to be super emphatic here.

[Art Vandelay]

chmod -R 777 /pathtofolder

[JDubya]

Yeah I've read a lot about the security risk so I contacted the developer about it. A couple of the folders I can get by with 755 as I won't be using them. They said the 'cache' folder is required by WordPress to be 777.

Lastly, the 'bills' folder is protected with an additional .htaccess file

Does this sound right? Will the .htaccess protect against the woes of 777?

[besson3c]

Originally Posted by JDubya 

Yeah I've read a lot about the security risk so I contacted the developer about it. A couple of the folders I can get by with 755 as I won't be using them. They said the 'cache' folder is required by WordPress to be 777.

No it's not. It's required to be writeable by the webserver.

Lastly, the 'bills' folder is protected with an additional .htaccess file

Does this sound right? Will the .htaccess protect against the woes of 777?

Yes, this is fine. You can do this with the cache folder too.

Sorry if I sounded preachy, I appreciate your awareness of this, I've just come across a bunch of people that just blindly do this and/or instructions that tell you to do this. It's very annoying.

[besson3c]

Even running locally, I'd still recommend either getting into URL rewriting/mod_rewrite/.htaccess files, or learning how to set directories to be writeable by the web server user, I just think it's bad practice for people in general to just chmod -R 777 stuff as a matter of habit.

Directing this at whomever else may come across this thread

[JDubya]

Originally Posted by besson3c 

No it's not. It's required to be writeable by the web server.

I didn't think so, as WordPress even warns against 777: Changing File Permissions � WordPress Codex

Originally Posted by besson3c 

Yes, this is fine. You can do this with the cache folder too.

I'll see if the developer can help me w/that as I've never worked with .htaccess before. My coding knowledge stops at minor aesthetic WordPress theme modifications.

Originally Posted by besson3c 

Sorry if I sounded preachy, I appreciate your awareness of this, I've just come across a bunch of people that just blindly do this and/or instructions that tell you to do this. It's very annoying.

Nope, not preachy at all. I appreciate the help!

Oh yeah, and this will be on shared hosting. I haven't purchased it yet but I'm leaning toward HostGator. I'm currently with GoDaddy but I'm switching

[besson3c]

I don't know why the WP team would instruct 777 perms, because there is literally no occasion when this is necessary with web stuff. WP just needs to read and write to this directory. Telling people to chmod 777 is just being lazy in making support easier.

[JDubya]

Good news, I got an update from the developer: "We have found that if your server communicates with PHP with CGI mode then folder permissions on 755 will work just fine."

So the terminal command is just:

chmod 777 /location/file

(I din't think i need to do it recursively) Do I need to do any follow up commands?

[besson3c]

No disrespect intended, but that developer is wrong.

He probably means PHP CGI + Suexec where the web server runs as the same owner as the user owning the files, in which case as long as you own everything (which you will on a shared host) the web server will be able to write to all directories.

This is different than PHP CGI though - with PHP CGI the same rules apply as PHP + Apache module (mod_php): that is, the directories you want to upload to need to be owned by the same username the web server runs as.

Unless you want to tinker with htaccess rules, don't chmod 777 the directory. Find out what username the webserver user runs as and:

sudo chown -R <webserveruser> /path/to/upload/directory

If you don't have SSH access and/or the ability to sudo that particular command you'll have to contact your hosting support, or do this through your cPanel or something (if your host has such a tool).

These same instructions apply to your WordPress cache directory - this directory just needs to be writable by the webserver username.

[JDubya]

This was the host's response: "use 755, it should work fine because of the suPHP environment that our accounts are on."

[besson3c]

Originally Posted by JDubya 

This was the host's response: "use 755, it should work fine because of the suPHP environment that our accounts are on."

Okay, so they are using suexec... That's fine then, 755 perms will work just fine. My point was that suexec (or what they call suPHP) is different than PHP running via CGI.