paulgorman.org/technical

RHCSA Study Notes

2021

Red Hat offers two Linux certifications: Red Hat Certified System Administrator (EX200) and Red Hat Certified Engineer (EX300). Red Hat allows three hours to complete the RHCSA exam.

Exam Objectives

https://www.redhat.com/en/services/training/ex200-red-hat-certified-system-administrator-rhcsa-exam?section=Objectives

Create Virtual Machines for Learning

Create a free Red Hat developer account, and download the RHEL ISO.

https://access.redhat.com/downloads/content/479/ver=/rhel—88.4/x86_64/product-software

Verify the download checksum.

🐚 ~ $ sha256sum rhel-8.4-x86_64-dvd.iso 
48f955712454c32718dcde858dea5aca574376a1d7a4b0ed6908ac0b85597811  rhel-8.4-x86_64-dvd.iso

Create two virtual machines:

$ sudo xhost +SI:localuser:root
$ sudo virt-install \
--name=rhvm1 \
--disk path=/home/paulgorman/virt/rhvm1.qcow2,format=qcow2,size=10 \
--os-variant=rhel8.4 \
--cdrom /home/paulgorman/virt/rhel-8.4-x86_64-dvd.iso \
--vcpus=1 \
--ram=1536 \
--graphics spice \
--network network=default

Create and configure file systems

Create and configure set-GID directories for collaboration

My questions

How are the initial permissions (from which the umask is subtracted) set?

Ghori writes that “initial permission values” are 666 for files an 777 for directories.

sudo grep -r 777 /etc | sed '/etc\/ssh/d' returns nothing of interest. I suspect 666 and 777 are hard-coded values. This seems to support the idea that these are hard-coded values — that they’re hard-coded in individual utilities, like mkdir and touch.

How would we change or override a user’s umask?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_managing-the-umask_configuring-basic-system-settings

Why is the umask different for root and non-root users? (And why are they the same on Debian 11?)

The justification for root to have a more conservative umask is security — files created by root with a umask of 022 will not be writable by the group, whereas files created by a user with umask 002 will be writable by the group.

How are the default umasks set?

--  redhat  ~ $ grep -C2 umask /etc/profile
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL

# By default, we want umask to get set. This sets it for login shell
# Current threshold for system reserved uid/gids is 200
# You could check uidgid reservation validity in
# /usr/share/doc/setup-*/uidgid file
if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
    umask 002
else
    umask 022
fi

🐚  debian  ~ $ grep -B25 -i 022 /etc/login.defs | tail -25
# Login configuration initializations:
#
#       ERASECHAR       Terminal ERASE character ('\010' = backspace).
#       KILLCHAR        Terminal KILL character ('\025' = CTRL/U).
#       UMASK           Default "umask" value.
#
# The ERASECHAR and KILLCHAR are used only on System V machines.
# 
# UMASK is the default umask value for pam_umask and is used by
# useradd and newusers to set the mode of the new home directories.
# 022 is the "historical" value in Debian for UMASK
# 027, or even 077, could be considered better for privacy
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
#
# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value
# for private user groups, i. e. the uid is the same as gid, and username is
# the same as the primary group name: for these, the user permissions will be
# used as group permissions, e. g. 022 will become 002.
#
# Prefix these values with "0" to get octal, "0x" to get hexadecimal.
#
ERASECHAR       0177
KILLCHAR        025
UMASK           022

How does umask work with ACL’s?

In a directory with a default ACL, the umask is ignored in favor of the default ACL.

🐚 debian ~ $ umask
022
🐚 debian ~ $ mkdir ~/test-umask
🐚 debian ~ $ touch ~/test-umask/test1
🐚 debian ~ $ stat ~/test-umask/test1 | grep Uid
Access: (0644/-rw-r--r--)  Uid: ( 1000/paulgorman)   Gid: ( 1000/paulgorman)
🐚 debian ~ $ 
🐚 debian ~ $ getfacl ~/test-umask/
getfacl: Removing leading '/' from absolute path names
# file: home/paulgorman/test-umask/
# owner: paulgorman
# group: paulgorman
user::rwx
group::r-x
other::r-x

🐚 debian ~ $ setfacl --default --modify other::0 ~/test-umask/ 
🐚 debian ~ $ getfacl ~/test-umask/
getfacl: Removing leading '/' from absolute path names
# file: home/paulgorman/test-umask/
# owner: paulgorman
# group: paulgorman
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:other::---

🐚 debian ~ $ touch ~/test-umask/test2
🐚 debian ~ $ stat ~/test-umask/test2 | grep Uid
Access: (0660/-rw-rw----)  Uid: ( 1000/paulgorman)   Gid: ( 1000/paulgorman)
🐚 debian ~ $ setfacl --default --modify other::rwx ~/test-umask/
🐚 debian ~ $ getfacl ~/test-umask/
getfacl: Removing leading '/' from absolute path names
# file: home/paulgorman/test-umask/
# owner: paulgorman
# group: paulgorman
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:other::rwx

🐚 debian ~ $ touch ~/test-umask/test3
🐚 debian ~ $ stat ~/test-umask/test3 | grep Uid
Access: (0666/-rw-rw-rw-)  Uid: ( 1000/paulgorman)   Gid: ( 1000/paulgorman)

umask(2) says:

The umask is used by open(2), mkdir(2), and other system calls that create files to modify the permissions placed on newly created files or directories. Specifically, permissions in the umask are turned off from the mode argument to open(2) and mkdir(2).

Alternatively, if the parent directory has a default ACL (see acl(5)), the umask is ignored, the default ACL is inherited, the permission bits are set based on the inherited ACL, and permission bits absent in the mode argument are turned off. For example, the following default ACL is equivalent to a umask of 022:

u::rwx,g::r-x,o::r-x

Combining the effect of this default ACL with a mode argument of 0666 (rw-rw-rw-), the resulting file permissions would be 0644 (rw-r–r–).

[…]

A child process created via fork(2) inherits its parent’s umask.

Since Linux 4.7, the umask of any process can be viewed via the Umask field of /proc/[pid]/status.

(Note, however, that when we run, e.g., umask -S, that umask is a shell built-in, rather than the system call described in umask(2).)