Folders Set So Anyone Can Write to Them

The setting nobody set back

An upload stopped working, or a plugin refused to install, or a gallery could not save its thumbnails. Someone searched for the error, found advice to set the folder to 777, and the problem went away.

Nobody set it back. The folder, and often everything inside it, has been writable by anything on the server ever since.

On a server of your own that is careless. On shared hosting, where hundreds of other accounts may run on the same machine, it leaves a door open.

The fix takes minutes once someone looks. The harder question is why the original problem seemed to need it.

What the numbers mean

Every file and folder on a web server has three sets of permissions, for its owner, a group and everyone else, each saying whether that party can read, write or run it.

• 644 for files: the owner can change them, everyone else can only read.
• 755 for folders: the owner can add files, everyone else can only look.
• Tighter for the configuration file holding the database password.
• 777 for nothing: anyone on the server can add, change or delete.

The last is the one to hunt for. A folder set to 777 accepts new files from any program on the server, including programs that have nothing to do with your site.

Why shared hosting makes it worse

On many older shared servers, the scripts of every site on the machine run as the same system user: the web server itself.

So a script on someone else's site can write into your 777 folder as easily as your own site can. If that other site is hacked, your folder is open to whoever hacked it.

The planted files are usually scripts: one that sends spam through your account, one that serves a phishing page from your domain, or one that lets an intruder come back whenever they like.

Why someone set it in the first place

Usually because the site's scripts ran as the web server while the folders belonged to the account. The scripts were not allowed to write to their own upload folder, and 777 was the quickest way round it.

Sometimes files were uploaded by FTP under one owner and created by the site under another, and neither could touch the other's work.

And sometimes an installation guide simply said to do it. Plenty of older plugins and scripts shipped with that instruction, and each case has a proper fix that does not open the folder to everyone.

A worked example

A yacht broker with a small office at a marina lists forty or fifty boats at a time, each with a gallery of photos uploaded through a listings script added to its website in 2010.

When the site moved hosts in 2012, photo uploads failed. The contractor handling the move set the listings folder and everything under it to 777, and uploads worked again.

This spring the host's scanner found a script among the boat photos that had no business being there. It had been sending mail through the account.

The cause of the 2012 failure turned out to be ownership. The moved files belonged to a different user from the one the site ran as, and the new host had run scripts as the account owner all along.

After the cleanup, the files were given to the right owner, folders went to 755 and files to 644, and the photo folders were set to refuse to run scripts. Uploads still work.

Checking the whole site

The file manager in your hosting control panel shows the permissions beside every file. So do most FTP programs, as a three-digit number or a row of letters.

Clicking through folders by hand misses things. Ask your developer or the host for a list of everything that everyone can write to, which on most servers takes one command.

Look hardest at upload folders, cache folders, and anything belonging to a plugin, gallery or form the site no longer uses.

Setting them correctly

Folders at 755 and files at 644 suit most sites on most hosts, with the configuration file set tighter than that.

Upload folders need to be writable by the site's own account and nobody else. Where the host runs scripts as your account, 755 is already enough.

Add a rule to each upload folder that stops scripts running there. Photos and documents never need to run, and a planted script that cannot run is harmless.

Some hosts that run scripts as the account refuse to run anything from a folder writable by everyone, and show a server error instead. That error is a sign the setting was wrong, not the host.

Ask what the fix was for

Before tightening anything, find out what loosened it, because the original problem is still waiting underneath.

Many hosts let you choose how scripts run from the control panel, or will change it on request. Running them as your own account removes the reason for 777 entirely.

If a plugin or script still insists on a folder open to everyone, treat that as a sign of its age. Software written properly for shared hosting does not need it.

Test after the change

Afterwards, try everything that writes a file: uploading an image, sending each form that takes an attachment, clearing the cache, running a backup.

Watch the error log for permission errors over the next week, since some tasks run only at night or weekly.

Anything that fails has found the real problem. Fix that, and leave the permissions where they are.

The counter-case

On a host that runs each site's scripts as its own account, a 777 folder is less exposed to the neighbours, because their scripts run as their own accounts and usually cannot reach into yours.

A small site with no uploads, forms or plugins has little that writes anything, and little to plant files into.

Neither is a reason to leave it. Your own weakest script, such as an old upload form, can still write anywhere it is allowed to, and hosting changes when sites move.

Set folders and files to what the site needs and no more, and fix the cause of any problem that seemed to need otherwise.

The check

1. Ask for a list of everything writable by everyone.
2. Find out why each one was opened.
3. Fix ownership or how the host runs scripts.
4. Set folders to 755 and files to 644.
5. Tighten the configuration file further.
6. Stop scripts running in upload folders.
7. Test every upload, form and backup.

Step three is what keeps the fix in place. Without it, the next failed upload brings the old advice back, and someone opens the folder again.

Other leftovers from old fixes that attackers look for are covered in an old form script still sitting in cgi-bin.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.