19.2 Manage Default File Permissions

19.2 Manage Default File Permissions

Quick Answer: umask controls the permission bits removed from default create modes. Defaults are typically file 666 and directory 777 before umask. Example: umask 022 → files 644, directories 755. Set for a session with umask 022; make user or system defaults persistent via shell startup files (and related system profiles). Verify by creating a file and directory and checking ls -l.

Official skill framing

Under Manage security, Red Hat expects you to manage default file permissions. Tasks sound like:

• “Ensure newly created files are not group- or world-writable by default.”
• “Set the default umask for user alice to 0077.”
• “Configure the system so new directories are 755 and new files are 644 for interactive users.”
• “Use a umask appropriate for a collaborative group directory (often 0002).”

This is not the same as chmod on existing trees. chmod fixes current objects; umask shapes future creates in processes that inherit that umask.

How umask calculates modes

Unix create defaults (common model used in training):

umask bits mark permissions to turn off.

Numeric examples

Mental math (octal):
result ≈ base & ~umask
Example: file base 666, umask 022 → clear write for group and other → 644.
Directory base 777, umask 022 → 755.

umask          # show current (often 0022)
umask -S       # symbolic form, e.g. u=rwx,g=rx,o=rx

Symbolic umask

umask u=rwx,g=rx,o=rx    # similar spirit to 022 for dirs
umask -S

On the exam, numeric three- or four-digit umask is most common in tasks and scripts.

Session umask (immediate)

umask 022
touch /tmp/tfile
mkdir /tmp/tdir
ls -l /tmp/tfile
ls -ld /tmp/tdir

Expected with 022: file mode 644, directory 755 (plus any ACL/special bits if present—focus on rwx triad).

umask 077
touch /tmp/secretf
mkdir /tmp/secretd
ls -l /tmp/secretf /tmp/secretd
# expect 600 and 700

Scope: umask built-in affects the current shell and processes it starts afterward. Other already-running daemons keep their own umask.

Per-user persistent umask

Interactive defaults usually come from shell startup files:

RHEL-style approach for one user:

# As alice or editing alice's files as root:
echo 'umask 027' >> /home/alice/.bashrc
# ensure login path sources bashrc if required by the shell setup

Or for login shells explicitly in ~/.bash_profile:

cat >> /home/alice/.bash_profile <<'EOF'
umask 027
EOF
chown alice:alice /home/alice/.bash_profile

After change, new login (or source the file) and re-test with touch/mkdir.

su - alice -c 'umask; touch /tmp/alice_f; mkdir /tmp/alice_d; ls -l /tmp/alice_f; ls -ld /tmp/alice_d'

System-wide default umask

When the task says all users or system default:

1. Inspect existing settings:

grep -R --line-number -E '^\s*umask' /etc/profile /etc/bashrc /etc/profile.d 2>/dev/null
grep -E '^UMASK' /etc/login.defs

1. Prefer a small snippet in /etc/profile.d/ for clarity (common admin pattern):

sudo tee /etc/profile.d/local-umask.sh <<'EOF'
# Default umask for interactive shells system-wide
umask 022
EOF
sudo chmod 644 /etc/profile.d/local-umask.sh

1. /etc/login.defs UMASK value influences some account/create paths and is part of the traditional login defaults story:

grep ^UMASK /etc/login.defs
# e.g. UMASK 022

On modern RHEL, shell startup files dominate interactive umask for users; still set login.defs if the task or local policy documentation points there. Read the task: “default umask for users” may mean profile.d/bashrc and/or UMASK in login.defs.

Do not randomly rewrite every package-owned file without understanding overrides—prefer profile.d drop-ins and user files the task names.

umask vs chmod vs ACL vs directory setgid

Shared project directories often combine:

• Directory mode 2775 (setgid + group write)
• umask 0002 so new files stay group-writable
• Correct primary/supplementary group membership

sudo mkdir -p /srv/project
sudo chgrp developers /srv/project
sudo chmod 2775 /srv/project
# users in developers with umask 002 create group-writable files

If umask is 022, new files become 644 and group cannot write even in a group-writable directory—classic collaboration bug.

Special bits reminder

umask does not “invent” setuid/setgid/sticky on new ordinary files. Sticky/setgid on directories are set with chmod on the directory itself. Keep umask tasks focused on ugo rwx defaults unless the scenario also asks for special bits.

Daemons and service umask

Systemd services may set UMask= in unit files. Changing your shell umask does not change httpd or nginx create modes. For EX200 “default file permissions” wording, focus on user/system shell umask unless the task explicitly targets a service unit.

Verification checklist

umask
umask -S
touch /tmp/umask_test_file
mkdir /tmp/umask_test_dir
stat -c '%a %n' /tmp/umask_test_file /tmp/umask_test_dir
ls -l /tmp/umask_test_file
ls -ld /tmp/umask_test_dir

For a named user:

su - username -c 'umask; touch ~/f; mkdir ~/d; stat -c "%a %n" ~/f ~/d'

Confirm numeric modes match the policy implied by the required umask.

Exam workflows

Workflow A — Session umask for testing

umask 022
touch /tmp/a; mkdir /tmp/b
stat -c '%a' /tmp/a /tmp/b   # 644 and 755

Workflow B — Harden user alice to owner-only creates

echo 'umask 077' | sudo tee -a /home/alice/.bashrc
sudo chown alice:alice /home/alice/.bashrc
su - alice -c 'umask; touch ~/x; mkdir ~/y; stat -c "%a" ~/x ~/y'
# expect 600 and 700

Workflow C — System-wide interactive umask 022

sudo tee /etc/profile.d/umask022.sh <<'EOF'
umask 022
EOF
sudo chmod 644 /etc/profile.d/umask022.sh
# new login shells pick this up

Workflow D — Collaboration-friendly umask 002

# For members of a shared project group
echo 'umask 002' >> ~/.bashrc
source ~/.bashrc
touch /srv/project/file1
ls -l /srv/project/file1   # expect group write if directory allows

Workflow E — Map required modes back to umask

If the task requires new files 640 and dirs 750, work backward:
files 640 from 666 → umask clears 026 for files; dirs 750 from 777 → umask 027. Use umask 027.

umask 027
touch /tmp/p; mkdir /tmp/q
stat -c '%a' /tmp/p /tmp/q

Common traps

1. chmod on one file when the task asked for default create permissions (umask).
2. Setting umask in a non-login shell file that never runs for the user’s login path—test with su - user.
3. Using umask 22 inconsistently vs 022/0022—understand leading zeros; values are octal.
4. Expecting umask to change existing tree modes—only new creates.
5. umask 0002 vs shared dir without group write/setgid—still incomplete collaboration design.
6. Editing only /etc/login.defs and assuming every interactive bash session changed without checking profile scripts (or the reverse).
7. Forgetting directories use 777 base, so the same umask yields different numeric modes than files.
8. Setting a extreme umask like 077 and breaking multi-user app home contents without need.
9. Confusing umask with ACL masks or SELinux—the mode triad is only DAC.
10. Not verifying with a fresh touch/mkdir after configuration.

Relationship to other sections

• Standard permissions (ugo/rwx): chmod/chown on existing objects; umask feeds new ones.
• Users/groups: collaborative umask pairs with group membership.
• SSH keys (19.3): ~/.ssh must often be 700 and keys 600—set with chmod after create; umask alone may not enforce those paths if tools set modes explicitly, but a loose umask can create over-permissive files if you copy secrets carelessly.
• Shell scripting: scripts may set umask near the top for predictable artifact modes.

Section checkpoint

You should explain how umask derives file vs directory modes, set session, per-user, and system-wide defaults appropriately, choose 022, 002, 027, or 077 for the scenario, verify with umask and test creates, and distinguish umask from chmod on existing data. That satisfies EX200 management of default file permissions on RHEL 10.