Red Hat System Administration II

A stock finance agency is setting up a collaborative share directory to hold case files, which members of the managers group will have read and write permissions on.

The co-founder of the agency, manager1, has decided that members of the contractors group should also be able to read and write to the share directory. However, manager1 does not trust the contractor3 user (a member of the contractors group), and as such, contractor3 should have access to the directory restricted to read-only.

manager1 has created the users and groups, and has started the process of setting up the share directory, copying in some templates files. Because manager1 has been too busy, it falls to you to finish the job.

Your task is to complete the setup of the share directory. The directory and all of its contents should be owned by the managers group, with the files updated to read and write for the owner and group (managers). Other users should have no permissions. You also need to provide read and write permissions for the contractors group, with the exception of contractor3, who only gets read permissions. Make sure your setup applies to existing and future files.

Important information:

1. The cases directory and its contents should belong to the managers group. New files added to the cases directory should automatically belong to the managers group. The user and group owners for the existing files should have read and write permission, and other users should have no permission at all.

   Note

   Hint: Do not use setfacl.

   1. Log in to serverb as the student user.

      [student@workstation ~]$ ssh student@serverb
      ...output omitted...
      [student@serverb ~]$ 

   2. Use the sudo -i command to switch to the root user. The password for the student user is student.

      [student@serverb ~]$ sudo -i
      [sudo] password for student: student
      [root@serverb ~]# 

   3. Use the chgrp command to recursively update group ownership on the directory and its contents.

      [root@serverb ~]# chgrp -R managers /shares/cases

   4. Use the chmod command to update the set-GID flag on the directory.

      [root@serverb ~]# chmod g+s /shares/cases

   5. Use chmod to update all existing file permissions to rw for owner and group.

      [root@serverb ~]# chmod 660 /shares/cases/*

   Hide Solution

2. Add ACL entries to the cases directory (and its contents) that allow members of the contractors group to have read/write access on the files and execute permission on the directory. Restrict the contractor3 user to read access on the files and execute permission on the directory.

   1. Use setfacl to recursively update the existing cases directory and its contents. Grant the contractors group read, write, and conditional execute permissions.

      [root@serverb ~]# setfacl -Rm g:contractors:rwX /shares/cases

   2. Use setfacl to recursively update the existing cases directory and its contents. Grant the contractor3 user read and conditional execute permissions.

      [root@serverb ~]# setfacl -Rm u:contractor3:rX /shares/cases

   Hide Solution

3. Add ACL entries that ensure any new files or directories in the cases directory have the correct permissions applied for all authorized users and groups.

   1. Use setfacl to update the default permissions for members of the contractors group. Default permissions are read, write, and execute (needed for proper subdirectory creation and access).

      [root@serverb ~]# setfacl -m d:g:contractors:rwx /shares/cases

   2. Use setfacl to update the default permissions for the contractor3 user. Default permissions are read and execute (needed for proper subdirectory access).

      [root@serverb ~]# setfacl -m d:u:contractor3:rx /shares/cases

   Hide Solution

4. Verify that you have made your ACL and file-system changes correctly.

   Use ls and getfacl to review your settings on /shares/cases.

   As the student user, use su - user to switch first to manager1 and then to contractor1. Verify that you can write to a file, read from a file, make a directory, and write to a file in the new directory. Use ls to check the new directory permissions and getfacl to review the new directory ACL.

   As the student user, use su - contractor3 to switch user. Try writing to a file (it should fail) and try to make a new directory (it should fail). As the contractor3 user, you should be able to read from the shortlist.txt file in the cases directory and you should be able to read from the "test" files written in either of the new directories created by manager1 and contractor1 users.

   Note

   The set of tests above are some of the tests you could perform to check that access permissions are correct. You should devise appropriate access validation tests for your environment.

   1. As the root user, use ls to check the cases directory and its content. Look for group ownership, directory and file permissions. The "s" in the group file permissions indicates the set-GID flag is set, and the "+" indicates that ACL entries exist. At the end exit from the root user session.

      [root@serverb ~]# ls -ld /shares/cases
      drwxrws---+ 2 root managers 46 Mar 29 00:40 /shares/cases
      [root@serverb ~]# ls -l /shares/cases
      total 8
      -rw-rw----+ 1 root managers 44 Mar 29 00:33 backlog.txt
      -rw-rw----+ 1 root managers 46 Mar 29 00:33 shortlist.txt

   2. Use getfacl and review its output. Look for the named user and named group entries in both the standard and default ACL.

      [root@serverb ~]# getfacl /shares/cases
      # file: shares/cases
      # owner: root
      # group: managers
      # flags: -s-
      user::rwx
      user:contractor3:r-x
      group::rwx
      group:contractors:rwx
      mask::rwx
      other::---
      default:user::rwx
      default:user:contractor3:r-x
      default:group::rwx
      default:group:contractors:rwx
      default:mask::rwx
      default:other::---
      
      [root@serverb ~]# exit
      logout

   3. Switch to the manager1 user and perform the following operations. Check that you get the expected access behavior.

      [student@serverb ~]$ su - manager1
      Password: redhat
      [manager1@serverb ~]$ cd /shares/cases
      [manager1@serverb cases]$ echo hello > manager1.txt
      [manager1@serverb cases]$ cat shortlist.txt
      ###Shortlist of Clients to call###TEMPLATE###
      [manager1@serverb cases]$ mkdir manager1.dir
      [manager1@serverb cases]$ echo hello > manager1.dir/test.txt
      [manager1@serverb cases]$ ls -ld manager1.dir
      drwxrws---+ 2 manager1 managers 22 Mar 29 00:59 manager1.dir
      [manager1@serverb cases]$ ls -l manager1.dir
      total 4
      -rw-rw----+ 1 manager1 managers 6 Mar 29 00:59 test.txt
      [manager1@serverb cases]$ getfacl manager1.dir
      # file: manager1.dir/
      # owner: manager1
      # group: managers
      # flags: -s-
      user::rwx
      user:contractor3:r-x
      group::rwx
      group:contractors:rwx
      mask::rwx
      other::---
      default:user::rwx
      default:user:contractor3:r-x
      default:group::rwx
      default:group:contractors:rwx
      default:mask::rwx
      default:other::---
      
      [manager1@serverb cases]$ exit
      logout

   4. Switch to the contractor1 user and perform the following operations. Check that you get the expected access behavior.

      [student@serverb ~]$ su - contractor1
      Password: redhat
      [contractor1@serverb ~]$ cd /shares/cases
      [contractor1@serverb cases]$ echo hello > manager1.txt
      [contractor1@serverb cases]$ cat shortlist.txt
      ###Shortlist of Clients to call###TEMPLATE###
      [contractor1@serverb cases]$ mkdir contractor1.dir
      [contractor1@serverb cases]$ echo hello > contractor1.dir/test.txt
      [contractor1@serverb cases]$ ls -ld contractor1.dir
      drwxrws---+ 2 contractor1 managers 22 Mar 29 01:05 contractor1.dir
      [contractor1@serverb cases]$ ls -l contractor1.dir
      total 4
      -rw-rw----+ 1 contractor1 managers 6 Mar 29 01:07 test.txt
      [manager1@serverb cases]$ getfacl contractor1.dir
      # file: contractor1.dir/
      # owner: contractor1
      # group: managers
      # flags: -s-
      user::rwx
      user:contractor3:r-x
      group::rwx
      group:contractors:rwx
      mask::rwx
      other::---
      default:user::rwx
      default:user:contractor3:r-x
      default:group::rwx
      default:group:contractors:rwx
      default:mask::rwx
      default:other::---
      
      [contractor1@serverb cases]$ exit
      logout

   5. Switch to the contractor3 user, and perform the following operations. Check that you get the expected access behavior.

      [student@serverb ~]# su - contractor3
      Password: redhat
      [contractor3@serverb ~]# cd /shares/cases
      [contractor3@serverb cases]# echo hello > contractor3.txt
      -bash: contractor3.txt: Permission denied
      [contractor3@serverb cases]# cat shortlist.txt
      ###Shortlist of Clients to call###TEMPLATE###
      [contractor3@serverb cases]# mkdir contractor3.dir
      mkdir: cannot create directory ‘contractor3.dir’: Permission denied
      [contractor3@serverb cases]# cat manager1.dir/test.txt
      hello
      [contractor3@serverb cases]# cat contractor1.dir/test.txt
      hello
      [contractor3@serverb cases]# exit
      logout
      [student@serverb ~]# 

   6. Log off from serverb

      [student@serverb ~]# exit
      logout
      Connection to serverb closed.
      [student@workstation ~]$ 

   Hide Solution