Setting permissions on files and directories

In this section, all the user management we've done in this chapter so far all comes together. We've learned how to add accounts, manage accounts, and secure them but we haven't actually done any work regarding managing the resources as far as who is able to access them. In this section, I'll give you a brief overview of how permissions work in Ubuntu Server and then I'll provide some examples for customizing them.

I'm sure by now that you understand how to list the contents of a directory with the ls command. When it comes to viewing permissions, the -l flag is especially handy, as the output that the long listing provides allows us to view the permissions of an object:

ls -l

The following are some example file listings:

-rw-rw-rw- 1 doctor doctor    5 Jan 11 12:52 welcome
-rw-r--r-- 1 root root     665 Feb 19  2014 profile
-rwxr-xr-x 1 dalek dalek      35125 Nov  7  2013 exterminate

In each line, we see several fields of information. The first column is our permission string for the object (for example, -rw-r--r--). We also see the link count for the object (second column), the user that owns the file (third), the group that owns the file (fourth), the size in bytes (fifth), the last date the file was modified (sixth), and finally the name of the file.

Keep in mind that depending on how your shell is configured, your output may look different and the fields may be in different places. For the sake of our discussion on permissions, what we're really concerned with is the permissions string, as well as the owning user and group. In this case, we can see that the first file (named welcome) is owned by a user named doctor. The second file is named profile and is owned by root. Finally, we have a file named exterminate owned by a user named dalek.

With these files, we have the permission strings of -rw-rw-rw-, -rw-r--r--, and -rwxr-xr-x respectively. If you haven't worked with permissions before, these may seem strange, but it's actually quite easy when you break them down. Each permission string can be broken down into four groups, as I'll show you in the following table:

I've broken down each of the three example permission strings into four groups. Basically, I split them each at the first character and then again every third. The first section of the permission string is just one character. In each of these examples, it's just a single hyphen. This refers to what type the object is. Is it a directory? A file? A link? In our case, each of these permission strings are files, because the first position of the permission strings are all hyphens. If the object were a directory, the first character would've been a d instead of a -. If the object were a link, this field would've been l (lower-case L) instead.

In the next group, we have three characters, rw-, rw-, and rwx respectively, in the second column of each object. This refers to the permissions that apply to the user that owns the file. For example, here is the first permission string again:

-rw-rw-rw- 1 doctor doctor 5 Jan 11 12:52 welcome

The third field shows us that doctor is the user that owns the file. Therefore, the second column of the permission string (rw-) applies specifically to the user doctor. Moving on, the third column of permissions is also three characters. In this case, rw- again. This section of the permissions string refers to the group that owns the file. In this case, the group is also named doctor, as you can see in column four of the string. Finally, the last portion of the permission string (rw- yet again, in this case) refers to world, also known as other. This basically refers to anyone else other than the owning user and owning group. Therefore, literally everyone else gets rw- permissions on the object.

Individually, r stands for read and w stands for write. Therefore, we can read the second column (rw-), indicating the user (doctor) has access to read and write to this file. The third column (rw- again) tells us the group doctor also has read and write access to this file. The fourth column of the permission string is the same, so anyone else would also have read and write permissions to the file as well.

The third permission string I gave as an example looks a bit different. Here it is again:

-rwxr-xr-x 1 dalek dalek 35125 Nov 7 2013 exterminate

Here, we see the x attribute set. The x attribute refers to the ability to execute the file as a script. So, with that in mind, we know that this file is actually a script and is executable by users, groups, and others. Given the filename of exterminate, this is rather suspicious and if it were a real file, we'd probably want to look into it.

If a permission is not set, it will simply be a single hyphen where there would normally be r, w, or x. This is the same as indicating that a permission is disabled. Here are some examples:

• rwx: Object has read, write, and execute permissions set for this field
• r-x: Object has read enabled, write disabled, and execute enabled for this field
• r--: Object has read enabled, write disabled, and execute disabled for this field
• ---: Object has no permissions enabled for this field

Bringing this all the way home, here are a few more permission strings:

-rw-r--r-- 1 sue accounting 35125 Nov 7 2013 budget.txt
drwxr-x--- 1 bob sales 35125 Nov 7 2013 annual_projects

For the first of these examples, we see that sue is the owning user of budget.txt and that this file is assigned a group of accounting. This object is readable and writable by sue and readable by everyone else (group and other). This is probably bad, considering this is a budget file and is probably confidential. We'll change it later.

The annual_projects object is a directory, which we can tell from the d in the first column. This directory is owned by user bob and group sales. However, since this is a directory, each of the permission bits have different meanings. In the following two tables, I'll outline the meanings of these bits for files and again for directories:

Files

Directories

As you can see, permissions are read differently depending on their context; whether they apply to a file or a directory. In the example of the annual_projects directory, bob has rwx permissions to the directory. This means that user bob can do everything (view the contents, add or remove contents, and use cd to move the current directory of his shell into the directory). In regards to a group, members of the sales group are able to view the contents of this directory and cd into it. However, no one in the sales group can add or remove items to or from the directory. On this object, other has no permissions set at all. This means that no one else can do anything at all with this object, not even view its contents.

So, now we understand how to read permissions on files and directories. That's great, but how do we alter them? As I mentioned earlier, the budget.txt file is readable by everyone (other). This is not good because the file is confidential. To change permissions on an object, we will use the chmod command. This command allows us to alter the permissions of files and directories in a few different ways.

First, we can simply remove read access from sue's budget file by removing the read bit from the other field. We can do that with the following example:

chmod o-r budget.txt

If we are currently not in the directory where the file resides, we need to give a full path:

chmod o-r /home/sue/budget.txt

But either way, you probably get the idea. With this example, we're removing the r bit from other (o-r). If we wanted to add this bit instead, we would simply use + instead of -. Here are some additional examples of chmod in action:

• chmod u+rw <filename>: The object gets rw added to the user column
• chmod g+r <filename>: The owning group is given read access
• chmod o-rw <filename>: Other is stripped of the rw bits

In addition, you can also use octal point values to manage and modify permissions. This is actually the most common method of altering permissions. I like to think of this as a scoring system. That's not what it is, but it makes it a lot easier to understand to think of each type of access as having its own value. Basically, each of the permission bits (r, w, and x) have their own octal equivalent, as follows:

• Read: 4
• Write: 2
• Execute: 1

With this style, there are only a few possibilities for numbers you can achieve when combining these octal values (each can only be used once). Therefore, we can get 0, 1, 2, 4, 5, 6, and 7 by adding (or not adding) these numbers in different combinations. Some of them you'll almost never see, such as an object having write access but not read. For the most part, you'll see 0, 4, 6, and 7 used with chmod most often. For example, if we add Read and Write, we get 6. If we add Read and Execute, we get 5. If we add all three, we get 7. If we add no permissions, we get 0. We repeat this for each column (User, Group, and Other) to come up with a string of three numbers. Here are some examples:

• 600: User has read and write (4+2). No other permissions are set. This is the same as -rw-------.
• 740: User has read, write, and execute. Other has nothing. This is the same as -rwxr-----.
• 770: Both user and group has full access (read, write, execute). Other has nothing. This is the same as -rwxrwx---.
• 777: Everyone has everything. This is the same as -rwxrwxrwx.

Going back to chmod, we can use this numbering system in practice:

• chmod 600 filename.txt
• chmod 740 filename.txt
• chmod 770 filename.txt

Hopefully you get the idea. If you wanted to change the permissions of a directory, the -R option may be helpful to you. This makes the changes recursive, meaning that you'll not only make the changes to the directory, but all files and directories underneath it in one shot:

chmod 770 -R mydir

While using -R with chmod can save you some time, it can also cause trouble if you have a mix of directories and files underneath the directory you're changing permissions on. The previous example gives permissions 770 to mydir and all of its contents. If there are files inside, they are now given executable permissions, since 7 includes the execute bit (value of 1). This may not be what you want. We can use the find command to differentiate these. While find is out of the scope of this chapter, it should be relatively simple to see what the following commands are doing and how they may be useful:

find /path/to/dir/ -type f -exec chmod 644 {} \;
find /path/to/dir/ -type d -exec chmod 755 {} \;

Basically, in the first example, the find command is locating all files (-type f) in /path/to/dir/ and everything it finds, it executes chmod 644 against it. The second example is locating all directories in this same path and changing them all to permissions 755. The find command isn't covered in detail here because it easily deserves a chapter of its own, but I'm including it here because hopefully these examples are useful and will be handy for you to include in your own list of useful commands.

Finally, we'll need to know how to change ownership of files and directories. It's often common that a particular user needs to gain access to an object, or perhaps we need to change the owning group as well. We can change user and group ownership of a file or directory with the chown command. As an example, if we wanted to change the owner of a file to sue, we could do the following:

chown sue myfile.txt

In the case of a directory, we can also use the -R flag to change ownership of the directory itself, as well as all the files and directories it may contain:

chown -R sue mydir

If we would like to change the group assignment to the object, we would follow the following syntax:

chown sue:sales myfile.txt

Notice the colon separating the user and the group. With that command, we established that we would like user sue and group sales to own this resource. Again, we could use -R if the object were a directory and we wanted to make the changes recursive.

Another command worth knowing is the chgrp command, which allows you to directly change group ownership on a file. To use it, you can execute the chgrp command along with the group you'd like to own the file, followed by the username. For example, our previous chown command can be simplified to the following, since we were only modifying the group assignment of that file:

# chown sales myfile.txt

Note

Just like with the chown command, we can use the -R option with chgrp to make our changes recursively, in the case of a directory.

Well, there you have it. You should now be able to manage permissions of the files and directories on your server. If you haven't worked through permissions on a Linux system before, it may take a few tries before you get the hang of it. The best thing for you to do is to practice. Create some files and directories (as well as users) and manage their permissions. Try to remove a user's access to a resource and then try to access that resource as that user anyway and see what errors you get. Fix those errors and work through more examples. With practice, you should be able to get a handle on this very quickly.