Posted on: 12 February 2014
Our first meetup this year was stymied a bit by the bad weather, but seven of us were there in the end and we had some good discussions — not only about the intended topics, but more besides.
As promised, I am putting up some documentation which for now mainly consists of an example of working with file permissions. If you’re like me, this is probably something you often kind of ‘muddled through’ without knowing all the details. I have certainly benefited from looking more closely at it.
Chrome Dev Tools
For the Chrome Dev Tools, this is a good tutorial to work through:
Also, check out Google's documentation here: https://developers.google.com/chrome-developer-tools/
File Permissions and Ownership
To get an overview about file permissions and ownership in your current directory, use the ls command with the -l flag (and -a for including dot files):
You can also check a single file by using the command like this: ls -l [filename] :
Each file is owned by a user(u) and a group user(g). A third category are all the other users(o).
CHMOD - Change permissions
The first column shows the set of permissions for the three types of users. There are many good resources on how the symbols map to the three user types, and how they can be translated into numbers, for example here: http://linuxcommand.org/lts0070.php
For changing permissions, you can then use the chmod command with symbols, for example:
or using the numeric interpretation:
About users and groups
Each user belongs to a group. When a new user is created, as default option a group with the user’s name will be created and the user assigned to it.
In this example, we will work with three users: root, www-data (the server user - or Apache user), and the login user
Some useful commands:
Who are you logged in as?
What groups do you belong to?
Some more information (IDs for the user and all the user’s groups) :
A list of all users on the system can be found in the file /etc/passwd, a list of all groups in /etc/group. Caveat: On a Mac things seem to be organised somewhat differently.
CHOWN - Change ownership
chown [OPTION]… [OWNER][:[GROUP]] FILE…
chown [OPTION]… –reference=RFILE FILE…
We will see this in action below.
Note: For changing permissions, it is sufficient to be the file owner, for changing ownership you always need root access.
A practical example - Increase security by restricting access
Note: This is assuming you are on a system that has an Apache server set up, which means there is a www-data user and group. If you don’t have that, just use a user and corresponding group of your choosing.
In your home directory - or even a local website directory if you have one for testing -, create a folder called ‘mycms’, then cd into it
Inside our cms we create an index file, a modules directory with two modules, and an upload directory.
What do we really need? The crucial thing is that the Apache user (www-data) needs to:
- read index.html
- read and traverse modules folders
- read and write to upload folder only
How can we do that?
- Keep ownership and write access with the login user
- Change the group to that of the Apache user, and assign it only read access
- The ‘other’ group will then not need any access at all for files being served
So we change group ownership recursively for the modules. Then we can change the permissions of ‘others’ to 0 (—), that of the Apache user to 5 (r-x)
Next, we change the group ownership for index.html. We don’t need executing rights here, because it’s a file, so we change permissions to 640 (- rw- r– —)
Uploads is a special case, because www-data needs to write here as well. We could still have www-data as group owner, and give write permissions, but can just as well have www-data as the user owner of the directory, and have a group of users as the group owner. The ‘others’ group still does not need any rights.
Question: What would be displayed if you have this running on a server, and you change the group of index.html back to your login user, but leave the permissions?
Setting permissions recursively
The above example was of course a very simplified version of a real CMS. You will often have many subdirectories with files and directories in there. In the Wordpress Codex, there is a good recipe for setting permissions for both recursively.
Security through restricting access
https://drupal.org/node/244924 http://codex.wordpress.org/Hardening_WordPress http://blog.sucuri.net/2012/07/wordpress-and-server-hardening-taking-security-to-another-level.html
Also interesting: Four different ways to create a user http://www.thegeekstuff.com/2009/06/useradd-adduser-newuser-how-to-create-linux-users/users/)
Learning linux commands and shell scripting from scratch: http://linuxcommand.org/