Permissions in your webserver

Not really a WebsiteBaker issue, but it is one of the most seen cause of problems.

A *nix (unix/linux) webserver uses a permissions method a bit different from what most people are used to see in Windows.
Files and directories are owned by a user in the system. All files can have permissions set to read/write/execute by the owner of the file, or by the group a user belongs to or just by everyone.
Users are typically 1) the website and 2) the FTP account.

Depending on the way your website host has setup your webspace these two users can be either the same or 2 different users.
When they are the same, you will have no problems with permissions. This is the case when your host uses fastCGI, suExec or mod_ruid2 to run PHP.

If your PHP is configured as an Apache module the website wil use a different user as the FTP user.

644, 755 or 777?

You might have seen these numbers before. They represent the bits set in files and directories for reading, writing and executing.
777 will allow all users to write into a file, or create new files, where 644 (for files) and 755 (for directories) only allows their owners to write or create something.

The problem now is that typically WebsiteBaker will be installed by uploading the installation files to your webserver. The FTP session will create the files and directories so they are all owned by the FTP user.

Whenever you want to install a new module or template using the WebsiteBaker admin installer the website needs to create a new folder in the /modules/ or /templates/ directory.
Unfortunatly the was created by the FTP user, so the website will not be allowed to do this.

The way to overcome this is to set the /modules/ (and templates) directory to 777 so the website can create its own files.

Typically a WebsiteBaker installation sets permissions on new installed files to 644 (and 755 for directories), meaning you cannot modify them using FTP. They may be located in a directory with 777 permissions, but the new directory will have 644/755 permissions owned by the website user.

The only way to reset this is by running a script or let your hosting controlpanel set new permissions for thise files.

What is wrong with 777?

If your host has configured your webserver correctly there will be no problems with 777.
Shared hosting servers with many webspaces should be configured in such way any webspace is limited to its own login (FTP) only, and PHP will only be able to reach files and directories configured for that account only.

I got hacked, and I have 777 set on directories.

If you got hacked this is probably done by getting access to your hosting account (FTP or controlpanel) or by getting access to your WebsiteBaker website as a user. Weak passwords, passwords used somewhere else, keyboard sniffers, accessing through public Wifi spots, etc etc are all possible causes why someone could get access to your website.

It really does not matter if you have used 644/755 or 777. The hacker can do the same as you can after he got access.

• If you can set permissions in FTP and a hacker found a way to login using FTP het can set permissions to whatever he likes.
• If you can create a new page when logged in in your website, so can a hacker.
• If you can install a module when logged in, so can a hacker.

Just by creating a page with a code block or even creating a droplet a hacker can create or upload a script that can access every file and database linked to that webspace.

So what should I do?

1. Check the reputation of your host. Try to find out if the configuration on his servers are good.
2. Use strong passwords everywhere (including databases and mailaccounts).
   Use some kind of password software to create them and keep them in a safe place.
3. Never use the same password on multiple websites
4. Never do any administration or FTP on public networks (including Internet café's)
5. Do not store passwords in your browser of FTP program.

Optionally you can have your website run a script on a regular basis to warn you whenever a file is created or modified.