You can closely control the access individual users and groups get to a file or directory by editing its permissions and ownership. In this video, we're going to learn how to define permissions and how to identify and control the ownership of a resource. We'll start with managing permissions. But before we learn how to do that, we should first make sure we understand how permissions are described by Linux. There are in fact, three separate notation systems you'll come across, which are effectively describing the same things. The first uses the letters R, W, and X. But also the letters, U, G, and O. R stands for read, meaning an object like a text file with the R value set, will be readable. W stands for write, meaning the object can be overwritten or edited or deleted for that matter. And X stands for executable. These values can be applied individually to different classes of user. U stands for user, meaning a given value like R or W can be applied to the particular user account that is the current owner of this object. G stands for group, the Linux group to which this object belongs. This will often be a group with the same name as the user. And O stands for others, which defines the access to this object given to any other user on the system.

Working with Linux permissions and ownership

Let's see how this works. Let's run ls -l, which will give us the long display or the status of all objects in the current directory. The D at the beginning of the first entry, tells us that it's a directory. We divide the next nine characters into three sets of three.

The first set defines the permissions that the current owner, the user, has on this object. In the case of the directory, we see R, W, and X. That means the directory's owner has read, write, and execute powers. The second set of three applies to the directory's group. It too has read, write, and execute powers.

Finally, the third set representing all other users, has read and execute powers, but not write. Others cannot edit or delete this directory.

The number that follows the permissions settings represents the number of hard links associated with this object. We're not concerned with that right now. The next value, Ubuntu in this case, is the object's owner. Ubuntu is the name of my user account on this virtual machine.

Ubuntu is also the name of the group associated with this object. We can, by the way, change an object's owner or group, using chown, change owner, where we specify the new owner, and if we like, the new group we'd like to associate with the directory. Then, the name of the resource. We use the -r switch to apply the operation to all the files and subdirectories within the directory. We need to use sudo because we're changing the profile of another user, in this case, Steve. If you want to change only the group but not its owner, you would use chgrp.

Getting back to the object notations. Looking at the file s3cmd-1.5.2.tar.gz, we see that there's a dash in the first position rather than a D, because this isn't a directory, but an individual file. The significant difference between the permissions for this file as opposed to the directory, is that the X permission, executable, happens to be missing for all three sets.

Permission values can also be represented by three numbers, which must add up to seven. Thus, read permissions are giving the octal value of four, write permissions, two, and executable permissions, one. To represent the values of the s3cmd-1.5.2 in my own example, the owner would get a value of seven: four for read, two for write, and one for executable, equaling seven. The group would also get seven, while others would get five: four for read, plus one for executable. But it's missing the two for write. The octal set, seven, seven, five would therefore accurately represent all three categories: user, group, and others. The S3cmd file, on the other hand, would get 664. Six for the owner of the group, representing read and write, and four for others, representing only read permissions.

We now know enough to edit permissions from the command line, using chmod. Since these objects now belong to Steve, we'll need to use sudo for these operations. Chmod works with both numbers and letters. Let's add write permissions for others to our file. Rather than six, six, four, we want it to be 666.

To do that, we'll run chmod 666 followed by the name of the object. Let's take a look to make sure it worked. We can also do this using characters. If we want to change the value back to what it was, we would have to remove write permissions from others. Let's run chmod with O minus W, meaning others will lose the W, write permission. To give other back that power, use the plus sign.

Let's review. Permissions can be applied in three different ways. To object owners designated as U for user, to groups, G, and to others, O. Permissions can be described either as octal values, four for read, two for write, and one for executable. They can also be described in a third way, in negative terms as we'll soon see with umask. Permissions can be described in characters, where R equals read, W equals write, and X equals executable. Chown can edit an object's owner and/or its group. Change group will edit its group only. Chmod followed by an octal value, like 775 will edit an object's permissions, as will a command like change mode G plus X.

Controlling access through the suid and guid

Sometimes, you'll need to allow temporary or specifically limited permissions to users for specific purposes. If a user has the right to execute a file, for instance, but for that instance and that instance only, you require that he can also act as the owner, you could use SUID, set user ID, to allow it. Here's a common example.

When a user wants to change his own password, he runs passwd, a program found in the /usr/bin directory. But changing a password will actually update system files in the /etc directory, to which this user has no rights. If, however, we can make the user temporary owner of /usr/bin/passwd, then his changes will be properly updated. Let's take a look at the password program file in /usr/bin. You can see the first set of permissions reads RWS rather than RWX or RW-. The S tells us that normal users executing this program will temporarily get the owners rights. Let's go back to our home directory and add the SUID to a file using chmod with U plus S. Listing the file once again, shows us an upper case S in the first set.

You might similarly want to add group powers to users executing resources belonging to specific groups, to make them temporary owners of these groups. As you might guess on your own, one way to do this is with G plus S. We'll delete the file, stuff. The sticky bit, when applied to a directory, protects privately owned files within the directory from being deleted by other users.

Here's a common scenario. Suppose we've got a directory that's shared by multiple users. Any user can create and edit files within the directory, but under normal circumstances, he can also edit and delete files in the directory created by others. If you'd like the directory and its contents to be shared, but wish to prevent users from changing the files created by other files, you apply the sticky bit. We'll create a new directory in /run called our files, and head over there to take a look.

We can add the sticky bit by simply running chmod and plus T. Listing the directory once again, shows us a T in the executable position from the others set. By the way, these operations can be performed using octal values as well. The SUID has an octal value of four, the SGID has two, and the sticky bit is one. You will place your choice in the first position of a octal operation, as in this example, which would add the sticky bit to this imaginary directory.

As a brief review, the SUID when set, gives users temporary ownership over a resource. You apply the SUID using chmod, U plus S. The GUID gives a user temporary group membership in an object. It's applied through chmod G plus S. The sticky bit protects files in a shared directory from being changed or deleted by other users. It's applied by using change mode plus T directory name.

Configuring umask values for Linux files and directories

Umask contains the default permissions value that the new files and directories will receive as they're created. But, and I assume this is just to confuse us, the value is displayed in a kind of mirror image. Let me explain. Let's run umask with no argument. We're shown that the current umask value for my user is 0002. For now, we'll ignore the first 0. Let's create a new file and use ls -l to view its permissions. We see that both its user and group have read and write permissions, while others have only read. Using our numeric notation, that would normally be 664, if you subtract 002 from a default value of 666, you'll get 664. So umask then, is the value you get by subtracting the normal notation value you'd like, say 664 from 666. Now let's change the umask. If we run umask itself again, we see that its value is changed.

This will apply read and write permissions to the file user, but only read and write to both its group and to others. Now let's create a new file and view its permissions We can see that Stuff1 can only be read, not overwritten by its group. You should be aware that the new value we've just given umask will only persist until this shell is closed. Let's exit the shell, log back in, and run umask again. And we'll see it's back to 002. This value is also only valid for this particular user. Any changes I apply to the Ubuntu user will have no affect on any other system account. We'll demonstrate that by becoming the admin, using sudo su.

Running umask as admin will return the value 0022. If you want to make your changes to umask persistent, you can edit either the etc/profile or etc/login.devs files. Let's quickly review umask. The umask, which is the default value a new file or directory will receive when its created, is represented as the total octal value minus its actual value. Thus, 0022, will be the umask that will produce objects with 755 permissions.