On a Linux system, permissions are used to secure access. In this chapter, you’ll learn how to modify ownership to accommodate permissions. To begin with, the basic read, write, and execute permissions are covered. Next, you’ll learn how to apply advanced Linux permissions for some extra security. Finally, at the end of this chapter you’ll learn how to create Access Control Lists to give permissions to more than one user or group and how to work with attributes to add an extra layer of protection to files.

Setting Ownership

File and directory ownership is vital for working with permissions. In this section, you’ll learn how you can determine ownership, as well as how to change user and group ownership for files and directories.

Displaying Ownership

On Linux, every file and every directory has an owner. To determine whether you as a user have permissions to a file or a directory, the shell checks ownership. First, it will see whether you are the user owner, which is also referred to as the user of the file. If you are the user, you will get the permissions that are set for the user, and the shell looks no further. If you are not the user owner, the shell will check whether you are a member of the group owner, which is also referred to as the group of the file. If you are a member of the group, you will get access to the file with the permissions of the group, and the shell looks no further. If you are neither the user nor the group owner, you’ll get the permissions of the others entity. This entity applies to everybody else.

From the above follows that permissions are not applied additive. That means that a user who is owner, but also is a member of the group that is owner, will only work with the user owner permissions and not with the group owner permissions.

To see current ownership assignments, you can use the ls -l command. This command shows the user as well as the group owner. In Listing 7-1, you can see the ownership settings for directories in the directory /home on a system that uses the public group approach where all users are members of the same group, users. In this output, you can see the name of the user owner in the third column, followed by the name of the group in the fourth column.

nuuk:/home # ls -l
total 24
drwxr-xr-x 8   alex         users 4096 Dec 12 12:02 alex
drwxr-xr-x 8   caroline     users 4096 Dec 12 12:02 caroline
drwxr-xr-x 8   linda        users 4096 Dec 10 11:36 linda
drwxr-xr-x 8   sander       users 4096 Dec 10 13:22 sander
drwxr-xr-x 8   sanne        users 4096 Dec 12 11:59 sanne
drwxr-xr-x 8   stephanie    users 4096 Dec 12 12:01 stephanie

Using the ls command, you can display ownership for files in a given directory. It may on occasion be useful to get a list of all files on the system that have a given user or group as owner. To do this, you may use find together with its -user argument. For instance, the following command would show all files that have user linda as their owner:

find / -user linda

You can also use find to search for files that have a specific group as their owner. For instance, the following command would search for all files that are owned by the group users:

find / -group users

Changing User Ownership

When working with permissions, it is important to know how to change file ownership. For this purpose, there is the chown command. The syntax of this command is not hard to understand:

chown who what

For instance, the following command would change ownership for the file account to user julie:

chown julie account

The chown command has one important option: -R. You may guess what it does, as this option is available for many other commands as well; it allows you to set ownership recursively, which allows you to set ownership of the current directory and everything below. This includes files as well as directories. The following command would change ownership for the directory /home and everything beneath it to user julie:

chown -R julie /home

Changing Group Ownership

You actually have two ways to change group ownership. You can do it with chown, but there’s also a specific command with the name chgrp that does the job. If you want to use the chown command, use a . or : in front of the group name. The following would change the group owner of directory /home/account to the group account:

chown .account /home/account

To see how to use the chgrp command to change group ownership, imagine the following example in which chgrp sets group ownership for the directory /home/account to the group account:

chgrp account /home/account

As is the case for chown, you can use the option -R with chgrp to change group ownership recursively. If you need to change user ownership as well as group ownership, chown offers you that option. After specifying the options, specify the username followed by a dot or a colon, and immediately after that the name of the group you want to set as the owner. As the last part of the command, mention the name of the file or the directory you want to set ownership for. For example, the following command would set user linda and group sales as the owner in one command:

chown -R linda.sales /home/sales

Default Ownership

You may have noticed that when a user creates a file, default ownership is applied. The user who creates the file will automatically become user owner, and the primary group of that user automatically becomes group owner. Normally, this will be the group that is set in the /etc/passwd file as the user’s primary group. However, if the user is a member of more groups, he or she can change the effective primary group using the newgrp command.

To show the current effective primary group, a user can use the groups command. The group that is effective as the primary group at that moment is listed first, followed by the names of all other groups the user is a member of. Following is an example:

linda@nuuk:~> groups
users dialout video

As an alternative, the id command can be used. This command shows information about a user account, in which the effective primary group is listed first.

If the current user linda wants to change the effective primary group, she can use the newgrp command, followed by the name of the group she wants to set as the new effective primary group. In Listing 7-2, you can see how user linda uses this command to make sales her effective primary group.

linda@nuuk:~> groups
users dialout video sales
linda@nuuk:~> newgrp sales
linda@nuuk:~> groups
sales dialout video users
linda@nuuk:~>

After changing the effective primary group, all new files that the user creates will get this group as their group owner. To return to the original primary group setting, use exit. This closes the subshell in which another effective primary group was used and will bring you back to the previous effective primary group setting.

Basic Permissions: Read, Write, and Execute

The Linux permissions system was invented in the 1970s. Since computing needs were limited in those years, the basic permission system that was created then was rather limited as well.

This system consists of three permissions that you can apply to files and directories. In this section, you’ll learn how the system works and how to modify these permissions.

Before doing this, let’s have a look at how to read the current permissions. The best method to do so is by using ls -l, which will show you a list of all files and directories in the current directory. The first character indicates the type of file. For instance, it gives d if it is a directory or l if it is a symbolic link. Next are nine characters to specify the permissions that are set to the file or directory. The first set of three are the user permissions, the next set of three are the group permissions, and the last set of three refer to the permissions granted to others. So in the example command listing that follows, user linda has rwx, group owner sales has r-x, and others have no permissions at all:

ls -ld /home/sales
drwxr-x--- 2    linda    sales    4096    sales

Understanding Read, Write, and Execute Permissions

The three basic permissions allow you to read, write, and execute files. The effect of these permissions will be different when applied to files or directories. If applied to a file, the read permission gives you the right to open the file for reading. This means that you can read its contents, but it also means that your computer can open the file to do something with it. A program file that needs access to a library might require, for example, read access to that library. From this, it follows that the read permission is the most basic permission you need to work with files.

If applied to a directory, read permission allows you to list the contents of that directory. You should be aware that this permission does not allow you to read files in the directory as well. The Linux permission system does not know inheritance, and the only way to read a file is by using the read permissions on that file. To open a file for reading, however, you do need read permissions to the directory, because you wouldn’t see the file otherwise. Notice that it’s not enough to have only read permissions on a directory. The read permission on directories always needs to be used together with the execute permission. Without execute permissions, users won’t be able to access the directory.

As you can probably guess, the write permission, if applied to a file, allows you to write in the file. Stated otherwise, write allows you to modify the contents of existing files. However, it does not allow you to create new files or delete existing files. To do that, you need write permission on the directory where you want to create the file. On directories, this permission also allows you to create and remove new subdirectories.

Note: Let me elaborate this with an example. If user root creates a file in the home directory of linda, is user linda allowed to delete that file or not? Many people give the wrong answer to this question: as root has created the file, the user linda has no write permissions on the file. This however doesn’t matter at all. To be able to remove a file, you need write permissions on the directory, and the permissions on the file don’t matter at all.

The execute permission is what you need to execute a file. That means that you’ll need execute on any program file or script file that you have created. It will never be set by default, which makes Linux almost immune to viruses. Someone who is owner of the directory will be capable of applying the execute permission to files in that directory. Also, if you’re owner of the file you cna use the chmod command to set the execute permission on that file.

Whereas the execute permission on files allows the user to run a program file, if applied to a directory, the user is allowed to use the cd command to go to that directory. This means that execute is an important permission for directories, and you will see that it is normally applied as the default permission to directories. Without it, there is no way to get into that directory! So if you want to have read permission on a directory, you must have execute permission as well. It makes no sense just to give a user read permission on a directory. Table 7-1 summarizes the use of the basic permissions.

Applying Read, Write, and Execute Permissions

To apply permissions, you use the chmod command. When using chmod, you can set permissions for user, group, and others. You can use this command in two modes: relative mode and absolute mode. In absolute mode, three digits are used to set the basic permissions. Table 7-2 gives an overview of the permissions and their numerical representation.

When setting permissions, you should calculate the value that you need. For example, if you want to set read, write, and execute permissions for the user, read and execute permissions for the group, and read and execute permissions for others on the file /somefile, you would use the following chmod command:

chmod 755 /somefile

When using chmod in this way, all current permissions are replaced by the permissions you set. If you want to modify permissions relative to the current permissions, you can use chmod in relative mode. When using chmod in relative mode, you work with three indicators to specify what you want to do. First, you’ll specify for whom you want to change permissions. To do this, you can choose between user (u), group (g), and others (o). Next, you use an operator to add or subtract permissions from the current mode, or set them in an absolute way. At the end, you use r, w, and x to specify what permissions you want to set.

When changing permissions in relative mode, you may omit the “to whom” part to add or remove a permission for all entities. For instance, the following would add the execute permission for all users:

chmod +x somefile

When working in relative mode, you may use more complex commands as well. For instance, the following would add the write permission to the group and remove read for others:

chmod g+w,o-r somefile

Before moving over to the advanced permissions, let’s practice applying basic permissions first.

Advanced Permissions

Apart from the basic permissions that you’ve just read about, Linux has a set of advanced permissions as well. These are special purpose permissions that have been added to the spectre of available Linux permissions later, to meet the demand for more advanced security settings.

Understanding Advanced Permissions

There are three advanced permissions. The first is the Set User ID (SUID) permission. On some specific occasions, you may want to apply this permission to executable files.

By default, a user who runs an executable file runs this file with his or her own permissions (provided that user has all permissions needed to run this file). For normal users, this normally means the use of the program is restricted. In some cases, however, the user needs to be able to run a command with root permissions. Consider, for example, the situation where a user needs to change his or her password. To do this, the user needs to write the new password to the /etc/shadow file. This file, however, is not writable for users with nonroot permissions:

nuuk:/home # ls -l /etc/shadow
-rw-r----- 1 root shadow 853 Dec 12 12:02 /etc/shadow

The SUID permission offers a solution for this problem. On the /usr/bin/passwd file, this permission is applied by default. So when changing his or her password, the user temporarily has root permissions, which allow the user to write to the /etc/passwd file. You can see the SUID permission with ls -l as an s at the position where normally you would expect to see the x for the user permissions:

nuuk:/ # ls -l /usr/bin/passwd
-rwsr-xr-x 1 root shadow 73300 May  4  2007 /usr/bin/passwd

The SUID permission may look useful—and it is—but at the same time, it is potentially dangerous. If applied wrongly, you may give away root permissions by . accident. I therefore recommend you use it with greatest care only. Let me explain why.

Imagine a shell script with the name gone that has the following contents:

#!/bin/bash
rm -rf /

Now imagine that user linda finds this shell script and tries to execute it. What will happen? She will remove her own files only. That is because for all the other files, she doesn’t have enough permissions to remove them. Now imagine that this shell script has root as its owner and the SUID permission set. So ls -l on this script would give the following:

ls -l gone
-rwsr-xr-x 1    root root     19    gone

But what happens if linda tries to run this script in this scenario? Can you imagine what would happen? It would actually remove all files on the hard drive of this computer, as the script is executed in a subshell where linda has root permissions. This is because user root is owner of the script, and the SUID permission is set. So linda would run it as root, and given this, she would have more than enough permissions to perform her destructive command. For that reason, there’s mainly one thing you need to remember about applying SUID: Don’t!

The second special permission is Set Group ID (SGID). This permission has two effects.

If applied on an executable file, it gives the user who executes the file the permissions of the group owner of that file. So SGID can accomplish more or less the same thing that SUID does. For this purpose, however, SGID is hardly used, and you should never apply it to accomplish this yourself!

When applied to a directory, SGID may be useful, as you can use it to set default group ownership on files and subdirectories created in that directory. By default, when a user creates a file, his or her effective primary group is set as the owner for that file. For example, if you have a shared group environment, this is not very useful, because no one else will be able to modify the files you’re creating, even if they’re member of the same group.

Imagine a situation where users linda and lori work for the accounting department and are both members of the group accounting. For security reasons, however, the administrator has decided to work with private primary groups. That means that linda is the only member of her primary group, linda, and lori is the only member of her primary group, lori. Both users, however, are members of the accounting group as well, but as a secondary group setting.

The default situation would be that when either of these users creates a file, the primary group becomes owner. However, if you create a shared group directory (say, /data/account) and make sure that the SGID permission is applied to that directory and that the group accounting is set as the group owner for the directory, all files created in this directory and all of its subdirectories would also get the group accounting as the default group owner. Notice that this is very useful behavior and for that reason, you should consider using SGID on all shared group environments.

The SGID permission shows in the output of ls -l with an s at the position where you normally find the group execute permission:

nuuk:/groups # ls -ld account
drwxr-sr-x 2 root account 4096 Dec 14 15:17 account

The third of the special permissions is sticky bit. This permission is useful to protect files against accidental deletion in an environment where multiple users can create files in the same directory. It is for that reason applied as a default permission to the /tmp directory.

Without the sticky bit permission, if a user can create files in a directory, he or she can also delete files from that directory. In a shared group environment, this may be annoying. Imagine users linda and lori both have write permissions to the directory /groups/account because of their membership in the group accounting. This means that linda is capable of deleting files that lori has created and vice versa. This may not be an ideal situation.

When applying the sticky bit permission, a user can delete files only if either of the following is true:

• The user is owner of the file.
• The user is owner of the directory where the file exists.

Notice that this means that sticky bit cannot be used to prevent users to remove files from their home directory. As the user is owner of the home directory, the user will always have permissions to remove files from this directory.

When using ls -l, you can see sticky bit as a t at the position where you normally see the execute permission for others:

nuuk:/groups # ls -ld account/
drwxr-sr-t 2 root account 4096 Dec 14 15:17 account/

Applying Advanced Permissions

To apply SUID, SGID, and sticky bit, you can use chmod as well. SUID has numerical value 4, SGID has numerical value 2, and sticky bit has numerical value 1. If you want to apply these permissions, you need to add a four-digit argument to chmod, of which the first digit refers to the special permissions. The following line, for example, would add the SGID permission to a directory, and set rwx for the user and rx for the group and others:

chmod 2755 /somedir

It is rather impractical if you have to look up the current permissions that are set before working with chmod in absolute mode (you would risk overwriting permissions if you didn’t). Therefore, I recommend working in relative mode if you need to apply any of the special permissions. For SUID, use chmod u+s; for SGID, use chmod g+s; and for sticky bit, use chmod +t followed by the name of the file or the directory that you want to set the permissions on.

Table 7-3 presents all you need to know about these special permissions.

When applying these permissions with chmod in absolute mode, you’ll use four digits (normally you would use three only) to set the permissions. Of these four digits, the first relates to the special permissions. So in the command chmod 4755 somefile, the SUID permission is set to somefile, and in chmod 3755, SGID as well as sticky bit are applied. In exercise 7-3 you’ll apply the advanced permissions to your test machine.

Working with Access Control Lists

Even with the additional features that were added with SUID, SGID, and sticky bit, serious functionality was still missing in the Linux permission scheme. In particular, the ability to grant multiple users and groups permissions to the same file or directory For that reason, Access Control Lists (ACLs) were added. In this section, you’ll learn what ACLs are and how to apply them.

Understanding ACLs

The Linux permissions system without ACLs has two serious shortcomings:

• There can only be one user owner and one group owner.
• It’s not possible to work with inheritance so that the permissions that are set on a higher level (such as a directory) are inherited to the lower level (such as the files in that directory).

These shortcomings are addressed by the ACL subsystem. By adding this feature to your file system, you can make it possible to grant permissions to additional entities on your file systems and work with inheritance as well.

Although the ACL subsystem adds great functionality to your server, there is one drawback: not all utilities support it. This means that you may lose ACL settings when copying or moving files, and also that your backup software may not be capable of backing up ACL settings. This doesn’t have to be a problem though. ACLs are often applied to directories to make sure that new files that are created in a directory will get the permissions you want them to have automatically. Consider ACLs as something that is applied when designing the file system lay-out, not as something that will be applied later. You will rarely set ACLs on individual files. This means you won’t have lots of ACLs, just a few applied on smart places in the file system. Hence, it will be relatively easy to restore the original ACLs you were working with, even if your backup software doesn’t support them.

Preparing Your File System for ACLs

Before starting to work with ACLs, you must verify that your file system supports ACLs. This isn’t always the case. If ACLs are not, you need to make sure your file system is mounted with the acl option (which most distributions will do automatically for you). For a mounted file system, you can do that by remounting the file system with the acl option. The following line shows how to do that for the root file system:

mount -o remount,acl /

The more elegant solution is to put the ACL option in fstab so that it is activated at all times when your system reboots. Listing 7-3 shows how this is done by default on a SUSE system. Notice that in this example, the user_xattr mount option has been used as well, to offer support for user extended attributes (discussed in more detail later in this chapter).

nuuk:/ # cat /etc/fstab
/dev/system/root     /      ext4    acl,user_xattr 1 1
/dev/sda1            /boot  ext4    acl,user_xattr 1 2
/dev/system/swap     swap   swap    defaults       0 0
...

Tip! It isn’t always very clear whether or not ACLs can be used on a file system. The best way to find out, is just be trying to apply the setfacl command as discussed below. If this command is giving you the “operation not supported” error message, ACL support is not available and you’ll need to fix this as described above.

Changing and Viewing ACL Settings with setfacl and getfacl

To work with ACLs, you need the setfacl command. This command has many options, some of them rather confusing. In this section, I’ll just discuss the useful options, which are not too hard to understand. The basic syntax of setfacl is as follows:

setfacl [options] operation entity:entityname:permissions file

In this example, the following components are used:

• Options: Use this part for specific options to moderate the way setfacl does its work. A few options can be useful:
  • -d: Use this option to set a default ACL. This is an ACL setting that is inherited by subdirectories and files as well.
  • -k: Use this option to remove a default ACL.
  • -R: Use this option to apply the ACL setting recursively.

• Operation: The operation tells setfacl to either add or remove an ACL setting. The following operations are available:
  • --set: Use this operation to set an ACL. It will replace any existing ACL, so use it with care.
  • -m: If you need to modify an ACL, use -m. It will not replace an existing ACL, instead adding to the current settings.
  • -x: Use this option to remove an existing ACL.
• Entity and entity name: These two define for whom you want to set the ACL. There are two types of entity: u for user and g for group. After specifying the type of entity, you need to specify the name of the entity.
• Permissions: These are the permissions that you want to set using ACLs. Use the Linux permissions as discussed previously.
• File: This is the name of the file or the directory to which you want to apply the ACLs.

Based on this information, it’s time to have a look at some examples, starting with some easy ones. Assume you want to add the group account as someone who has rights (this is called a trustee) to the directory account. The setfacl command to do this would be as follows:

setfacl -m g:account:rwx account

However, it does not make sense to start working on ACLs without having a look at the current permissions first. Therefore, in Listing 7-4, you can see the permission settings for the directory /groups/account before and after I’ve changed the ACL.

nuuk:/groups # ls -l
total 4
drwxr-sr-t    2 root users 4096 Dec 14 15:17 account
nuuk:/groups # setfacl -m g:account:rwx account
nuuk:/groups # ls -l
total 8
drwxrwsr-t+ 2 root users 4096 Dec 14 15:17 account

As you can see, there was already a group owner, users, and this group owner was not touched by changing the ACLs with setfacl. The only thing indicating that something is going on is the + sign that is shown directly after the permission listing in ls -l. This + indicates that an ACL is effective.

To see the ACLs themselves, you need the getfacl command. In Listing 7-5, you can see what this command shows for the directory account on which I’ve just applied an ACL.

nuuk:/groups # getfacl account
# file: account
# owner: root
# group: users
user::rwx
group::r-x
group:account:rwx
mask::rwx
other::r-x

As you can see in the output of getfacl, this command shows you the names of user and group owners and the permissions that are set for them. Following that, it shows there is also a group account that has rwx permissions. Just ignore the information that is shown in the mask line; ACL masks are a complex and confusing feature that you only need to compensate for in a bad directory structure design, and therefore I will ignore it in this book. On the last line, the permissions of others are displayed as well.

In the second example, I’ll show you how to modify an existing ACL so that it becomes a default ACL. Basically, you use the same command that you’ve seen before, but with the option -d added to it. Also, the command adds a second group in the ACL setting by using a comma to separate the names of the two groups:

nuuk:/groups # setfacl -d -m g:account:rwx,g:sales:rx account

At this moment, you have a default ACL. This means that all files and all directories created under /groups/account will get the same ACL setting. You can show this with the getfacl command, as demonstrated in Listing 7-6.

nuuk:/groups # getfacl account
# file: account
# owner: root
# group: users
user::rwx
group::r-x
group:account:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:sales:r-x
default:group:account:rwx
default:mask::rwx
default:other::r-x

As you can see, shown are not only the user and group owner names, but also their permissions and the default settings that will be applied to new files. You should notice that at this point, however, an interesting mix exists between the normal Linux permission scheme and the ACL settings. This shows when user linda, who belongs to the group users, creates a subdirectory in the directory /groups/account. You can see the getfacl result on that directory in Listing 7-7: for the “normal” user and group owners, the normal rules of ownership are applied, and the ACL settings are added to that. This means that when you are working with default ACLs, you should always carefully plan what you want to do before applying them!

linda@nuuk:/groups/account> getfacl subdir
# file: subdir
# owner: linda
# group: users
user::rwx
group::r-x
group:sales:r-x
group:account:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:sales:r-x
default:group:account:rwx
default:mask::rwx
default:other::r-x

You have now learned how to work with an ACL. This is a useful feature if you need to enhance the capabilities of Linux file system permissions. I personally rely on it a lot when configuring a Linux file server, which typically is an environment where one group has requirements different from another group. I’ve also used it on a web server environment to grant access to a developer to all the files in the HTML document root without changing the default permissions in that environment, which could have negative impact on the working of the web server. Use this feature sparsely though, because a Linux system that has too many ACLs applied is a Linux system that is more difficult to understand.

Setting Default Permissions with umask

In the discussion about ACLs, you have learned how to work with default ACLs. If you don’t use ACLs, there is a shell setting that determines the default permissions that you will get: umask. In this section, you’ll learn how to modify default permissions using this setting.

You have probably noticed that when creating a new file, some default permissions are set. These permissions are determined by the umask setting, a shell setting that is applied to all users when logging in to the system. In the umask setting, a numeric value is used that is subtracted from the maximum permissions that can be set automatically on a file; the maximum setting for files is 666 and for directories is 777. In other words, to derive numeric permissions from the umask, subtract the umask from 666 for files and from 777 for directories.

There are, however, some exceptions to this rule; you can find a complete overview of umask settings in Table 7-4. Of the digits used in the umask, like with the numeric arguments for the chmod command, the first digit refers to end-user permissions, the second digit refers to the group permissions, and the last refers to default permissions set for others. The default umask setting of 022 gives 644 for all new files and 755 for all new directories that are created on your server.

There are two ways to change the umask setting: for all users and for individual users. If you want to set the umask for all users, you must make sure the umask setting is entered in the configuration file /etc/profile. If the umask is changed in this file, it applies to all users after logging in to your server. You can set a default umask by just adding a line like the following to /etc/profile:

umask 027

An alternative to setting the umask in /etc/profile, where it is applied to all users logging in to the system, is to change the umask settings in a file with the name .profile, which is created in the home directory of an individual user. Settings applied in this file are applied for the individual user only; therefore this is a nice method if you need more granularity. I personally like this feature to change the default umask for user root to 027, whereas normal users work with the default umask 022 on many distributions.

Working with Attributes

Permissions always relate to a trustee, which is a user or a group who has permissions to a file or directory. Attributes offer a different way to specify what can be done to a file. Attributes do their work, regardless of the user who accesses the file. Of course, there is a difference: the owner of a file can set file attributes, whereas other users (except for root who is almighty) cannot do that. Working with attributes is useful in some cases, but it’s not very common.

For file attributes as well, an option must be provided in /etc/fstab before they can be used. This is the user_xattr option that can be seen in the fstab example in Listing 7-3 earlier in this chapter. Some attributes are available, but not yet implemented. Don’t use them, because they bring you no benefit. Following are the most useful attributes that can be applied:

• A: This attribute ensures that the access time of the file is not modified. Normally, every time a file is opened, the file access time must be written to the file’s metadata. This affects performance in a negative way; therefore, on files that are accessed on a regular basis, the A attribute can be used to disable this feature.
• a: This attribute allows a file to be added to, but not to be removed. For example, you could use it on log files as an additional layer of security that ensures that entries can be added, but the log file cannot be removed by accident.
• c: If you are using a file system where volume-level compression is supported, this file attribute makes sure the file is compressed the first time the compression engine gets active.
• D: This attribute makes sure that changes to files are written to disk immediately, and not to cache first. This is a useful attribute on important database files to make sure that they don’t get lost between file cache and hard disk.
• d: This attribute makes sure the file is not backed up in backups where the dump utility is used.
• I: This attribute enables indexing for the directory where it is enabled (see Chapter 5 for more details on indexing). This allows faster file access for primitive file systems like Ext3 that don’t use a b-tree database for fast access to files.
• j: This attribute ensures that on an Ext3 file system the file is first written to the journal and only after that to the data blocks on the hard disk. Use this to make sure that the journal offers maximum protection, and the chance of losing data is reduced to a minimum.
• s: This overwrites the blocks where the file was stored with zeros after the file has been deleted. This makes sure that recovery of the file is not possible after it has been deleted.
• u: This attribute saves undelete information. This allows a utility to be developed that works with that information to salvage deleted files.

If you want to apply attributes, you can use the chattr command. For example, use chattr +s somefile to apply the attribute s to somefile. Need to remove the attribute again? Then use chattr -s somefile, and it will be removed. To get an overview of all attributes that are currently applied, use the lsattr command.

Summary

In this chapter, you have learned how to work with permissions. You’ve first discovered the role of ownership when determining your effective permissions. Next, you have learned about the three basic permissions: read, write, and execute. Following that, you have seen how to work with advanced features such as the SUID, SGID, and sticky bit permissions as well as ACLs. You’ve also read how to apply file attributes to add an additional layer of security to your file system. In this chapter, the following commands have been discussed:

• chown: Change ownership of files and directories.
• chgrp: Change group ownership of files and directories.
• groups: List group ownership for users.
• newgrp: Temporarily change the effective primary group for a user.
• chmod: Change permission mode on files and directories.
• setfacl: Set ACLs.
• getfacl: Read current ACLs.
• chattr: Change file attributes.
• lsattr: List file attributes.

In the next chapter, you will learn about process management.