Permissions and Ownership - CompTIA Linux+ / LPIC-1 Cert Guide (Exams LX0-103 & LX0-104/101-400 & 102-400) (2016)

CompTIA Linux+ / LPIC-1 Cert Guide (Exams LX0-103 & LX0-104/101-400 & 102-400) (2016)

Chapter 10. Permissions and Ownership

This chapter covers the following topics:

Image Working with Permissions

Image Manipulating Permissions

Image Special File Permissions

Image Finding Files by Permission

Image Default Permissions

Image Changing User Ownership

Image Changing Group Ownership

This chapter covers the following objectives:

Image Manage file permissions and ownership: 104.5

Both regular users and administrators should understand the importance of object permissions and object ownership. Ensuring that your files and directories are secure is critical. This chapter explores the concepts of object permissions, special permission sets, default permission, and object ownership.


We use the term “object” to denote something that is either a file or directory.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 10-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”


Table 10-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Which command lets you alter the default permissions in a shell?

a. chmod

b. chgrp

c. chown

d. umask

2. Consider the following ls –l output:

-rwxr-xr-- 2 fred users 0 Jan 26 13:08 22 sample.mp3

What are the permissions for the user fred on the sample.mp3?

a. Read, write, and execute

b. Read and execute

c. Read and write

d. Only read

3. Which command adds execute permission to all permission sets (owner, group, and others)?

a. chmod u+x file

b. chmod u=x file

c. chmod a+x file

d. chmod g+x file

4. Which command sets the sticky bit permission on the /dir directory?

a. chown +t /dir

b. chmod o+t /dir

c. chmod u+t /dir

d. chmod g+t /dir

5. You have been asked to find all the SUID files on the system. Which of the following commands completes this task?

a. find / -perm -6000

b. find / -permission -6000

c. find / -mode -6000

d. find / -umask -6000

6. Consider the following command

chown bob:bin file.txt

Which of the following statements are true? (Choose two.)

a. This changes the user owner of file.txt to bin.

b. This changes the user owner of file.txt to bob.

c. This changes the group owner of file.txt to bin.

d. This changes the group owner of file.txt to bob.

7. The user nick owns the file.txt file. He is a member of the payroll and sales group, with the payroll group being his primary group. He executes the following command:

chgrp sales file.txt

Which of the following statements is true?

a. This command fails because nobody but the root user can change the group ownership of a file.

b. This command fails because a user can only change the group ownership of a file to his primary group.

c. This command fails because the order of the arguments is wrong.

d. This command works and changes the group owner of the file to sales.

Foundation Topics

Working with Permissions

Permissions determine how users can access resources on the system. System security is configured by the user’s UID (user ID), her GIDs (group ID—both primary and secondary), and the permissions on the object she is attempting to access.


Permission Trio Bits

Figure 10-1 shows the 10 positions (1 type bit and 3 trios of permission bits) that make up the permissions section of a file.


Figure 10-1 Permission trios

The first bit of the 10 shown is the type of object:

Image .—Indicates that this is a normal file

Image l—Indicates that this is a symlink (symbolic link), which is a file that points to another object

Image b—Indicates that this is a block device file

Image c—Indicates that this is a character device file

Image d—Indicates that this is a directory

The next nine bits are what I call the permission trios. Each of the trios affects a certain set of users (user owner, group owner, or other). To determine which permissions a user has to a given object, begin from the left and as soon as a match is made, that trio alone is the permissions in effect for that user and object. Here are the three trios:

Image User owner—If the user is the user owner, this is the permission trio in effect.

Image Group owner—If the user’s primary or secondary groups are this group, but only if that user is not the user owner, this is the permission trio in effect.

Image Other—If the user is neither the user owner nor a member of the group owner, this is the permission trio in effect.


On some modern Linux systems, you see another character right after the permission set. This could either be a “.” character, which is related to SELinux, or a “+” character, which is related to access control lists (ACLs). Both of these topics are not testable on the LPIC-1 exams. Do not mix up the Windows environment and Linux in your mind. There is no such thing as “effective permissions” for a Linux object; that is entirely a Windows concept. For example, a user who matches the user owner and is also a member of the group owner does not have the greater permissions of the two trios slapped together; he is restricted only to the user owner trio’s permissions.

The trios are made up of 3 bits (symbolized by the values of 4, 2, 1). The bits work like light switches: If the bit is on, then the value counts; if off, the value doesn’t count. That value is used with the chmod command as well as with other commands.


The bit values equate to the following permissions for files:

Image 4—Read, which is the ability to view the file’s contents.

Image 2—Write, which is the ability to change the file’s contents.

Image 1—Execute; the file can be executed. (The read is also needed for a script, but binaries can execute with only the execute permission.)


These permissions have similar, but slightly different, meanings for directories:

Image 4—Read, which is the ability to view the directory’s contents (using the ls command). However, to see file attributes (such as with the –l option to the ls command), execute permission on the directory is also required.

Image 2—Write, which is the ability to add and delete files in the directory. This is a powerful permission for directories as a user can delete every file in a directory, even files that she doesn’t own, if she has the write permission on the directory. Caveat: For write permission to be valid, the user also must have execute permission.

Image 1—Execute; the user can use the cd command to get into the directory or use the directory in a pathname. For example, if the user attempts to execute cd /home/bob, the user needs execute permission on the / directory, the home directory, and the bob directory.

To better understand directory permissions, think of the directory as a room. If you want to see what is in the room, you need a window. Think of the read permission as the window. If this permission is set, you can see into the directory (room). If you want to get into the room, you need a door. Think of the execute permission as the door. This concept makes the caveat for the write permission make more sense: To remove something from a room, you first need to be able to get into the room!

If you execute the ls –l command on an object and its permission trios are 666 (or rw-rw-rw-), the only way that number could be arrived at with the possible bit values is for the 4 and 2 bits to be on, or rw- (read and write, but not execute). If you see a file that is set to 666, that equates to all three trios having the same permissions—read and write, but not execute.


Watch for questions that try to trick you with a user who is both the user owner and a member of the group owner, but the correct permissions for executing or changing the file aren’t in a single trio. You can’t mix the trios, even if your user account encompasses several of the trios.

For example, say a user named fred is the user owner of the file object /home/fred/22AcaciaAvenue.mp3 and is also a member of the group owner of that object. The file’s listing has the following permissions set:

-rw-r-xr-x 2 fred users 0 Jan 26 13:08 22 AcaciaAvenue.mp3

The fred user’s permissions might seem to span the various trios, but because fred is the user owner, he matches the first trio and stops there. In other words, the user fred has read and write permission, but not execute, even though fred is a member of the users group and members of that group do have execute permission on this file.

Manipulating Permissions

The chmod command is used when modifying or altering an object’s permission trio bits. Only the root and object’s owner can alter permissions.

The two modes of manipulating the permissions for an object are numeric and symbolic. Both modes have their place; the numeric method is better for changing all permissions while the symbolic method is better for changing one or two permissions.

Numeric Mode


Numeric permissions are the most often used, and they appear on the exam with greater frequency than the symbolic style. As a rule, I recommend using the numeric mode to set or force permissions on an object, as opposed to making small changes to permissions.

The numeric method uses the same bits to describe what you want your permissions to be (4=read, 2=write, 1=execute). For example, if you are told that the current permissions for an object are 644 and you are asked to ensure that all users have read and write access to that object, execute the following command:

chmod 666 file1

The chmod command works great on groups of files, too:

chmod 644 /home/lukec/*.txt

It even works on directories and their contents. For example, say the user bertrandr has a directory that he wants to set all the files to the permission of 640 to make the files more secure. He could use the following command:

chmod –R 640 /home/bertrandr/data/*

Take a moment to understand why this command works the way it does. The chmod command has an -R option that affects the object named and all its child objects. The user bertrandr doesn’t want to change the permission of the data directory itself, but just the contents, which is why the slash and asterisk characters are on the end of the target. This command acts on the entire contents of the /home/bertandr/data directory but doesn’t modify the directory’s permissions. However, if there were any directories within the /home/bertandr/data directory, all those directories would have the permissions changed (as well as all files and directories beneath them)!

The chmod command has a few useful options:

Image -c—Reports only which files were changed

Image -v—Reports all files

Image -h—Changes symbolic links, not the original file

Image -f—Suppresses error messages

Image -R—Operates recursively through directories

The chmod command’s recursive option is an uppercase “R,” not a lowercase “r” as in some other commands. Familiarize yourself with the case of the various command options, and you will be fine on the exam.


When using the numeric method, you should always specify three values (owner, group, and others). If you only specify one value, it uses that value for the others permission set and assumes a value of 0 for the owner and group permissions. This is never a good idea!

Symbolic Mode


When using the chmod command with symbolic values, keep in mind that you can change all the permissions like the numeric mode, but this requires a much longer command. The primary reason to use symbolic mode is to affect, or alter, smaller sets of permissions rather than to overwrite them all.

The symbolic mode uses a letter to identify the trios:

Image User owner = u, group owner = g, other = o, and all = a

Image A qualifier (+ to add, - to remove, or = to assign)

Image The permissions being set (r = read, w = write, and x = execute)

To use the symbolic values to set permissions, you can change them all at once, like the following command demonstrates:

chmod a=rwx file

This produces permission trios that are set to -rwxrwxrwx.

Or you can use each one of the identifiers with its qualifier and permissions separated by commas:

chmod u=rw,g=rx,a= file

This produces a file that has its permissions set to –rw-r-x---.

This method of using the symbolic mode is viewed as unwieldy and somewhat inelegant for constant use. Use symbolic mode when you want to fine-tune the permissions, not set all the permissions.

For example to change just the user owner’s permissions to rwx, use the following command:

chmod u=rwx mystuff

To change the group owner’s permissions to r-x, use the following command:

chmod g=rx mystuff

To change the other or everyone else’s permissions to r, use this command:

chmod o=r mystuff

Keep in mind, when using the symbolic mode, the permissions that you are not specifying stay as they were before executing the chmod command.

Setting a file to be executable without knowing its other permissions can be done several ways. For example, if you know a file exists but don’t know the permissions and you are told to make sure it’s executable by all permission trios, use the following command:

chmod a+x file1

Alternatively, you can leave the “a” off and get all the trios by default:

chmod +x file1

Remember: When changing permissions you can always use either the numeric method or the symbolic method. The numeric method is normally easier when changing all the permissions, while the symbolic method is normally easier when changing one or just a few permissions.

Special File Permissions

Several facts about how the Linux and Unix file systems are constructed can cause problems for administrators. For example, only a single group can be the group owner for a given object. Whoever wants access to that object needs to be a member of the group that owns the file (unless you, as the owner of the file, want to give permission to all others). For example, consider the following ls –l output:

-rw-r----- 1 bob staff 0 Jan 26 13:08 22 data.txt

To be able to see the contents of this file, you either need to be the bob user or a member of the staff group.

Trying to configure many groups and users to have access to the right files can be difficult. Every user has a primary group, and they could be a member of additional groups (secondary groups). This poses problems when sharing files between members who are in “shared” secondary groups. Consider the following scenario:

The bob user (primary group: staff, secondary group: project), the sue user (primary group: payroll, secondary group: project), and the steve user (primary group: acct, secondary group: project) are working on a joint project and sharing files in the /home/project directory. The bob user creates a file that ends up looking like the following when listed with the ls –l command:

-rw-r----- 1 bob staff 0 Jan 26 13:08 22 data_for_sue_and_

Unfortunately, even though all users are in the same group (the project group), the sue and steve users can’t view the contents of this file. They are not members of the staff group, so their permission set is “others” for this file.

As we see later, the bob user can change the group ownership of the file to the project group, but this relies on users performing this action every time they create a file. It is unreasonable to assume that all users will remember to do this all of the time (and as an administrator you don’t want to have to teach every user to perform this action on their files).

There’s a way out of this situation: You can set an additional or special bit on the shared directory, which causes all users who have access to inherit the group owner of the directory on all objects that they create in that directory. This permission set, called SGID, is covered in detail later in this chapter.


There are now access control lists (ACLs) on some Linux distributions, which allow for much more fine-tuning of permissions. However, ACLs are not on the exam, so be careful when answering exam questions related to special bit and group ownership.

Special Bit Permissions


The following special bits are available for Linux file system use:

Image SUID—The Set User ID (SUID) permission allows users to run a program as if they were the user owner of the program; in most cases the user owner is the root user. The numeric value of this permission set is 4XXX (where “XXX” is replaced by the numeric values for the trio sets mentioned previously).

Image SGID—When set on a directory, the Set Group ID (SGID) permission automatically gives group ownership of all new files created in the directory to the group owner of the directory (numeric = 2XXX). When set on a file, the SGID allows users to run a program as if they were the group owner of the file.

Image Sticky bit—This permission set is used to keep “nonowners” from deleting files in a common directory (numeric = 1XXX). In a sticky bit directory, only the owner of the file or the owner of the directory can delete the file (root always can delete files as well).


Remember that these special permissions are used only when necessary, which isn’t often; the SUID and SGID permission sets on an executable file pose a security risk, even when properly used. Avoid providing write permission to SUID and SGID executables. This permission gives a regular user the ability to replace the code within the file, providing a security hole on the system.

Special permissions can be set either of two ways—numeric or symbolic, just like setting other permissions with the chmod command.

The use of the characters XXX in the following examples indicates that permissions exist and need to be included but removes the focus from the permissions. In other words, these are the regular permissions that we previously discussed, and I substituted the XXX characters to focus on the special bits instead.

The first way to set these special permissions is to use the numeric mode when executing the chmod command. All permissions must be overwritten when using numeric mode; the following sets the SUID permission on the file:

chmod 4XXX /some/program

Several bits can be changed or set simultaneously; the following command sets both the SUID and SGID bits for the program (which is somewhat rare, but permitted):

chmod 6XXX /some/program

The second way to set special permissions is to use the symbolic mode. For example, to add SUID on a file:

chmod u+s /some/program

Again, you can set several special bits at once even with the symbolic mode, although the syntax is a bit more complex:

chmod u+s,g+s /some/program

Setting the SUID Bit on Files


A good example of the SUID bit is an existing command: chsh. The chsh command allows a regular user to change her login shell. Note the current permissions for this command:

-rws--x-- 1 root root 15432 Apr 29 2013 /usr/bin/chsh

The s in place of the user owner’s execute permission indicates this is an SUID command. When this command executes, it modifies the contents of the /etc/passwd file. The /etc/passwd file is not normally something that can be modified by non-root users; as you can see, normally only the root user has this ability:

-rw-r--r-- 1 root root 2036 Mar 8 18:39 /etc/passwd

However, with the SUID permission set, the chsh program is able to access files as either the person who runs the command or as the owner of the chsh program (which, in this case, is root).

What if you, as the administrator, do not want users to change their login shells? Just execute the following command as root:

chmod u-s /usr/bin/chsh

Example 10-1 shows a live example.

Example 10-1 Demonstration of SUID

[root@localhost ~]# ls -l /usr/bin/chsh
-rws--x--x. 1 root root 15432 Apr 29 2013 /usr/bin/chsh
[root@localhost ~]# su - student
[student@localhost ~]$ chsh
Changing shell for student.
New shell [/bin/bash]: /bin/csh
Shell changed.
[student@localhost ~]$ exit
[root@localhost ~]# chmod u-s /usr/bin/chsh
[root@localhost ~]# su - student
[student@localhost ~]$ chsh
Changing shell for student.
New shell [/bin/csh]: /bin/bash
setpwnam: Permission denied
Shell *NOT* changed. Try again later.


While the user can “try again later” as the last line of output suggests, until the root user resets the SUID permission set, no regular user will be able to change his login shell.

Setting the SGID Bit on Files

The SGID permission is rarely set on files. Consider the following program with the SGID bit set:

-r-xr-sr-x 1 root tty 10996 Jul 19 2011 /usr/bin/wall

The s in place of the group owner’s execute permission indicates this is an SGID command. The wall command allows users to send messages to the terminal windows of all users logged in. Normally this would be a security issue; you don’t want a user to interfere with another user’s terminal window. Having a message pop up in a terminal where a user is working can be distracting.

The reason why users can use the wall command in this way is because it is an SGID program. When this program executes, it accesses files as if the person executing the command were a member of the tty group. This, in turn, allows the wall program to have write access to the terminal device files group owned by the tty group:

[root@localhost ~]# ls -l /dev/tty1
crw--w---- 1 root tty 4, 1 Jun 2 17:13 /dev/tty1

Having problems with users abusing the wall command? Take away the SGID access:

chmod 0555 /usr/bin/wall


The wall program can be used to communicate with others users, but since maturity levels vary among humanity and definitely among computer users, you may have users harassing others, or inappropriately sending broadcast messages, so by restricting the user’s access to this command, you improve all system user’s productivity.

Setting the SGID Bit on Directories

Consider the previously discussed scenario:

The bob user (primary group: staff, secondary group: project), the sue user (primary group: payroll, secondary group: project), and the steve user (primary group: acct, secondary group: project) are working on a joint project and sharing files in the /home/project directory. The bob user creates a file that ends up looking like the following when listed with the ls –l command:

-rw-r----- 1 bob staff 0 Jan 26 13:08 22 data_for_sue_and_

Recall that this results in a problem: Even though bob, sue, and steve all have a common group, sue and steve can’t access this file. If bob were to change the group ownership to the project group, then sue and steve would be able to view the contents of this file. However, expecting users to do this every time they create a file isn’t reasonable.

The solution is to add SGID permission to the /home/project directory:

chmod g+s /home/project

As the preceding command changes the group ownership to be the projects group, this means all new files created in the /home/project directory are automatically group owned by the group owner of the directory (which would have to be set to the project group, of course). Note: This doesn’t solve the problem of the existing file, only for new files.

Setting the Sticky Bit


The sticky bit is used mostly for ensuring that users in a shared directory can’t delete anyone else’s files. A good example of this is the /tmp directory:

drwxrwxrwt 29 root 4096 Jun 2 17:27 /tmp

The t in place of the others execute permission indicates this is a sticky bit directory. The /tmp directory is a location where all users must be able to create files. Unfortunately, the permission that allows users to create files also allows them to delete files—all files—in that directory.

By adding the sticky bit permission, the write permission for directories changes meaning. Instead of meaning “add and delete all files in the directory,” the only users who can now delete files in this directory are

Image The owner of the file or

Image The owner of the directory (which is normally the root user) or

Image The root user

Anyone can still add a file into this directory, as long as it doesn’t result in overwriting another user’s file.

Finding Files by Permission

Attackers who breach your system often attempt to set certain files to have the SUID or SGID bit set, allowing their otherwise normal account to perform all sorts of unauthorized tasks.


The find command has an operator that makes finding your vulnerable files easy. The -perm operator is usually followed by a three- or four-digit set of permissions, such as the example shown here:

find /usr/bin -perm 777

This example searches for any object in the /usr/bin directory and all subdirectories that has the exact permissions of rwxrwxrwx. This is fine, but it doesn’t help find security risks caused by the SUID and SGID bits. This next command does, however:

find / -perm -4000

At first glance, this might look as if we’re searching for all files that have the SUID bits and then blank permissions from that point on. It really searches the entire system for all files that have the SUID bit set, regardless of the other permissions.

You should install the system and then run a find command that reports any file that has an SUID bit set, like so:

find / -perm -4000 -ls

Redirect this output to a file and keep that file on a disk or in some safe place off the system (like on a USB drive). Every so often (especially after installing new software or when you think your system has been exploited), you should run the same find command and then compare the results to the original with the diff command, such as:

diff /root/latestfindperm /mnt/usb/findperm.orig

Investigate any differences!

Default Permissions

Consider the following situation: You create a new file and it has the permissions of rw-rw-rw- on it. You realize that this is much too “open,” so you execute the following command to place the permissions that you want on this file:

chmod 640 file

Ten minutes later you create another file, and it also has the permissions of rw-rw-rw- on it. Again you execute the chmod command to set the permissions of 640 on the file. You begin to realize that you are going to be executing the chmod command a lot. Fortunately, there is a better way.


If your system is a typical Linux system, a value is set in either the /etc/bashrc or ~/.bashrc file that governs the default permissions any created object has. This value is known as the umask, and this single value is used to determine default permissions for both directories and files. This umask only applies when you create a new file or directory.

The maximum default permissions for directories and files are different, which means the umask value results in different default permissions for files than it does for directories. The default permissions with no umask value set are

Image For files: rw-rw-rw- (or 666)

Image For directories: rwxrwxrwx (or 777)

View the umask for your current shell by executing the following command:


This just means that of the four possible positions to mask out (special permissions, user owner permissions, group owner permissions, and other permissions), the last two have the write permission masked out or not used. Note: The first position never has any effect as the special permissions are never set by default. As a result, the umask value of 0022 is really the same as 022.

If you create a file when the umask is set to 022, the file’s permissions is as follows:

-rw-r--r-- 1 root root 881 Feb 17 09:11 file1

If you create a directory with the same umask set, the directory’s permissions are as follows:

drwxr-xr-x 2 root root 4096 Feb 17 14:47 dir1

To understand why these permission sets are different, think about the process of how the umask is applied. To begin with, recall the default permissions:

For Files For Directories
Maximum rw-rw-rw- rwxrwxrwx

Now, consider a umask value of 022. This means you are “masking out” or removing the write permissions for the group owner and others (represented by the M values here):

For Files For Directories
Maximum rw-rw-rw- rwxrwxrwx
MASK ----M--M- ----M--M-

When those permissions are masked out, you end up getting the following permissions on new files and directories:

For Files For Directories
Maximum rw-rw-rw- rwxrwxrwx
MASK ----M--M- ----M--M-
Result rw-r--r-- rw-r--r--

As you can see, the umask value changes the default permissions of a created object based on the following formula:

Maximum default value – umask value = create value

You can change the umask value to a more restrictive one with the umask 027 command.

Now, you can create another file and the permissions should be

-rw-r----- 1 root root 881 Feb 17 09:22 file2

Create another directory with the umask value of 027 and the permissions should be

drwxr-x--- 2 root root 4096 Feb 17 14:48 dir2

Notice that in the previous example the umask has a value greater than the default value of the file being created. The umask values go from 000 to 777 because a directory object has a maximum default value of 777; however, files have a maximum default value of 666. The umask value must encompass both sets of possible values, so if you have a 7 in a umask value, it would affect the file default permission as if it were a 6. In other words, in this case 6 – 7 = 0.


The umask value will show up on the exam. For example, you might see a question that provides a file permission listing and be asked to provide the umask value that resulted in those permissions. To become familiar with how umask values work, try different scenarios to determine what the result would be. Use the following chart and plug in different values for your umask value for practice:

For Files For Directories
Default rw-rw-rw- rwxrwxrwx

Finally, it is important to note that while each of your shells initially has the same umask value, you can change this value in one shell and it does not affect the umask value in other shells. Recall that this value is initially set via an initialization file (typically either the /etc/bashrc or~/.bashrc file).

Changing User Ownership


The chown command is used to set the user owner, group owner, or a combination of the two with one command. The format for the chown command is

chown -options user:group object

The chown command accepts both of the following commands as valid (the owner/group separator can be either a “:” or a “.” character):

chown snuffy:users file1
chown snuffy.users file1

In addition, you can use the following syntax with chown:

Image owner—Changes only the user owner

Image owner:group—Changes both the user owner and group owner

Image owner:—Changes the user owner and sets the group owner to the primary group of the current user

Image :group—Changes only the group owner and leaves the user owner unaffected

Let’s say that the user snuffy’s primary group is called users and the account is a secondary group member of the accounting group. By default, every object snuffy creates on the system has snuffy as the user owner and users as the group owner. This can cause problems in shared directories.

If snuffy visits a shared directory whose group ownership is set to the accounting group and creates a file named snuffysexpenses.txt, that file is inaccessible to any of the other users who share that directory unless they are also members of the group users.

Say the user martha does expenses and needs to have ownership of the file and you, as the administrator, want to change the group ownership of this file to the accounting group. To accomplish this task, use this command:

chown martha:accounting snuffysexpenses.txt

Let’s say that now the file needs to be owned by another user who cuts the checks, fluchre; you can change just the user owner without having to bother with the group owner:

chown fluchre snuffysexpenses.txt

If for some reason you decide that an entire directory tree of files needs to have its ownership changed, you can change them all with the following command:

chown –R root:accounting /accounting


Important note: The only user on the system who can change the user ownership of an object is the root user. Even the owner of the file can’t “give ownership” to another user. However, a regular user can change the group ownership of an object as long as the user is a member of the group that she is changing ownership to.

Changing Group Ownership


When just the group owner needs to be changed, the simplest method is to use the chgrp command. The syntax of the command is straightforward:

chgrp staff file1

Changing a large set of files to another group owner requires the use of the -R (recursive) option:

chgrp –R staff /data/*

The previous command changes the contents of the /data directory (and all its subdirectories) to the group owner staff but leaves the user owner alone.

Options for the chgrp command include

Image -c—Shows a line of output only for changed objects

Image -h—Changes symbolic links, not the original file

Image -R—Recursively affects the target and all children

Image -v—Shows a line of output for every object, regardless of the actions performed on the object


Although it is not an exam objective, the newgrp command can be handy when it comes to group ownership. A regular user can execute the command newgrp groupname if he is a member of groupname. This opens a new shell in which the primary group is groupname. This is useful when creating a bunch of files that need to be group owned by a secondary group. To close this new shell, simply execute the exit command.


In this chapter you learned the concept of basic permissions, including how to set them and how to specify the default permissions for objects. You also learned how special permissions work and how they are important for securing the system.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a few choices for exam preparation: the exercises here, Chapter 21, “Final Preparation,” and the practice exams on the DVD.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 10-2 lists a reference of these key topics and the page numbers on which each is found.



Table 10-2 Key Topics for Chapter 10

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

permission trios

numeric mode

symbolic mode



sticky bit

umask value

Review Questions

The answers to these review questions are in Appendix A.

1. The execute permission for directories provides what access?

a. The ability to list file names in a directory

b. The ability to add files to the directory

c. The ability to remove files from the directory

d. The ability to change into the directory

2. Consider the following output of the ls –l command:

-rw-rwxr-x 2 fred users 0 Jan 26 13:08 22 test.mp3

Which of the following statements is true?

a. The user fred has only read permission on test.mp3.

b. The user fred has only read and write permission on test.mp3.

c. The user fred has read, write and execute permission on test.mp3.

d. The user fred has no permission on test.mp3.

3. Which of the following is the equivalent to the command chmod 644 file.txt?

a. chmod a+r,ug+w file.txt

b. chmod u+rw,g+r,o+r file.txt

c. chmod u=rw,go=r file.txt

d. chmod ugo+r,u+w file.txt

4. Which of the following commands sets the SUID permission? (Choose two.)

a. chmod u+s file

b. chmod g+s file

c. chmod 2755 file

d. chmod 4755 file

5. Consider the following command:

umask 077

Assuming this command was executed in the current shell, which of the following are true? (Choose two.)

a. A new directory created in this shell would have the permissions of rw-------.

b. A new directory created in this shell would have the permissions of rwx------.

c. A new file created in this shell would have the permissions of rw-------.

d. A new file created in this shell would have the permissions of rwx------.