Every file is made up of a permission set. These permissions consists of 3 sets of 3 bits for a total of 27 configurations. Just kidding! It’s not that complex!
Let’s take a look at output from a FTP client. Three files and 1 directory exist in this example. A directory, tmp/, denoted by “d” is also called a folder: a place to stash files. Each file has different permission sets, which permit different interactions.
Permissions are broken into chunks that consist of read (r), write (w), and execute (x) properties. Read permits access to read file or folder contents, write permits access to modify the file or remove files within a directory, and execute allows the file to run as a program or to open a directory. An absence of a permission is replaced by “-“.
Note: a directory could have just execute (x), lack read (r), and still be accessible by a user. File contents could not be listed, but if the filename were known, then it could be opened. This approach is recommended in multi-user accounts to protect against file snooping.
Likewise, if a directory lacks an execute bit (x), then neither it nor any directories within it may be opened.
Each file or directory consists of 3 chunks that are applied to the file owner, group, and everyone else (simply called “other“). Notice how each file has two users next to it?
These 2 fields represent the owner and group to which the file belongs. Owner is the user who created the file, and group is the group to which the user belongs. “Everyone else” is everyone else who isn’t the owner nor a member of the group, in particular the web server that runs as user “apache” in its own group. Only user admin can write to the file. Other users created via Users > Add User can read the file, as can the web server, in addition to the creator, admin.
Any file created by a user on your account will possess the same group, which is the primary username of the account. A special user “apache” is any file created by a web application. Permissions are applied nightly to permit modification by the primary user on the account. Ownership can be changed via Files > File Manager > Properties action within the control panel.
Permissions must be changed to allow another user, like a PHP application, write access to the file. But before that, take a quick aside to learn about the alternative form of presenting permissions…
Permissions can be presented in set or octal form. Previously permissions were presented as sets for easy understanding. Now, map each permission type: [r,w,x] into a number: [4, 2, 1]. Add these numbers up for each permission chunk and you get a 3-digit number between 0 and 7 that represents permissions for the owner, group, and other.
-rw----r-- becomes 604,
drwxr-xr-x becomes 755, and so on. Whenever permissions are referred to as “777”, this maps to
Permissions from now on will be referred to in octal for brevity.
Permissions may be edited in a variety of ways:
- FTP client. See FTP access KB article for details
- Web-accessible FTP client via ftp.hostineer.com. Select chmod operation.
- Within the control panel: Files > File Manager > Properties action
- Terminal: chmod
Permissions may be applied to a single file or directory, or recursively to all files and directories within a directory. Files created after changes are applied will not inherit these new permissions and must be reapplied as necessary.
777 is a simple way to allow every user access to modify, create, and delete files. Often 777 is recommended to allow a PHP application access to create files. Yes, it does work and on Apis Networks’ hosting platform is quite secure (PHP undergoes a separate round of security checkpoints), but other users on your account also have access to read, modify, and delete files. It is, therefore, recommended to specify 717 instead of 777 to lockout other users on your account from making adjustments to files. PHP applications will still be able to write to those files – and only those files – explicitly granted by 717 permissions.
Why use multiple users?
Computing power has grown exponentially over the last decade; the cost to crawl a web site and brute-force has decreased. Along with the growth of knowledge, attackers have become more sophisticated carrying out attacks through elaborate botnets consisting of several hundred thousand machines. Common exploitable vectors include weak FTP passwords for other users on your account as well as outdated web applications. These vectors are continuously accessed by unauthorized users throughout the day from thousands of IP addresses that slip below detection thresholds. Such attacks are orchestrated from a single command-and-control sever that command infected machines to periodically try a login/password combination.
A single machine may probe a site 2-5 times per hour (once every 12 minutes). Multiplied out by 10,000 different machines in a botnet, 1,200,000 combinations per day is enough to try every possible 4-letter password combination consisting of lowercase letters and numbers 0-9 in only 1 day or test every known WordPress exploit against 65 different sites each day.
- Attacks do happen, and the level of sophistication is much greater than a decade ago.
- Use separate users to restrict the impact of an unauthorized breach.
- Judiciously apply permissions to only those files that the web server or other users must have access to modify.
Reduce your risk and impact by utilizing multiple users.