Loading...

VONDS ©

Lab 10: Manage File Permissions and Ownership

Back to Lab Index

Investigate and correct overly permissive access on a sensitive log file in /var/log using ownership and permission controls. Validate the result and set a more secure default behavior using umask.

security users core

Scenario

You’ve received a report that the audit.log file in /var/log is accessible to users who should not see it. You must inspect the current permissions, adjust ownership, restrict access, and confirm the system’s default permission behavior.

Operator context

This is the kind of cleanup you do after an audit finding or a sloppy manual change, before assuming the logging pipeline or service configuration is the real problem.

Objective

  • Inspect permissions and ownership on /var/log/audit.log.
  • Remove unintended access for “others” using chmod.
  • Set the correct group owner for controlled log access.
  • Apply a strict numeric permission mode for the final state.
  • Check the current umask and set a more secure default.

Concepts

  • Treat ls -l as your baseline evidence: owner, group, and permission bits before any change.
  • Prefer group-based access for shared operational workflows (grant group read, manage membership).
  • Use numeric modes when you want an audit-friendly end state that is unambiguous (example: 640).
  • umask controls defaults for newly created files. Fixing one file is not the same as fixing the default posture.
  • “Secure by default” is about preventing future drift, not just correcting one bad permission.

Walkthrough

Step 1: Inspect current permissions and ownership.
Command 
ls -l /var/log/audit.log

Start by proving the current state. This tells you the owner, group, and permission bits so you can identify exactly what is wrong before changing anything. 

# Example (problem state):
-rw-r--r-- 1 root root 4523 Jul 18 14:32 /var/log/audit.log
Step 2: Remove read access for “others.”
Command 
chmod o-r /var/log/audit.log

This is the quickest way to eliminate unintended disclosure without changing owner or group access. It narrows the problem and is a safe first hardening step. 

ls -l /var/log/audit.log
# Confirm "other" no longer has 'r'.
Step 3: Set the correct group owner for controlled access.
Command 
chgrp adm /var/log/audit.log

Assigning a dedicated log-reading group is a common operations pattern. You grant access to the group and manage membership instead of widening file permissions. 

ls -l /var/log/audit.log
# Confirm group owner is: adm
Step 4: Apply least-privilege permissions (rw-r-----).
Command 
chmod 640 /var/log/audit.log

Using a numeric mode makes your intended end state explicit. 640 sets owner read/write, group read-only, and no access for others. This is a clean, audit-friendly final state. 

ls -l /var/log/audit.log
# Expected pattern:
-rw-r----- 1 root adm ... /var/log/audit.log
Step 5: Check the current umask.
Command 
umask

umask defines which permission bits are removed from newly created files by default. If your environment is creating files too open, this is part of the root cause. 

# Example:
0022
Step 6: Set a stricter umask for secure defaults.
Command 
umask 0027

0027 is a common secure default. For files, starting from 666 and applying a mask of 027 results in 640. This aligns with “owner full access, group read-only, others none.” 

umask
# Confirm:
0027

Common breakpoints

Permissions look correct, but access is still blocked

Permissions are only one layer. Confirm the user is actually in the group you’re granting access to, and consider SELinux contexts if your distro enforces them.

Group is set, but group members still cannot read

Verify the file mode includes group read (r). A common mistake is using 600 when you meant 640.

umask change does not persist

umask 0027 affects the current shell session. If you need persistence, set it in the appropriate shell profile or system defaults for your environment.

Log file permissions keep reverting

The generating service may be rewriting the file or applying its own settings. Confirm service defaults and any log rotation rules that might be resetting ownership or mode.

Cleanup checklist

This lab changes file permissions and may change the current shell’s default umask. Confirm the final state matches what you intended.

Commands 
ls -l /var/log/audit.log
umask
Success signal

/var/log/audit.log shows -rw-r----- with group adm, and your umask matches your intended default.

Reference

  • ls -l: Displays file permissions, owner, group, size, and timestamp.
  • chmod o-r <file>: Removes read permission from “others” without affecting owner and group permissions.
    • o: Others.
    • -r: Remove read bit.
  • chgrp <group> <file>: Changes a file’s group ownership to control access via group membership.
    • <group>: Target group (example: adm).
  • chmod 640 <file>: Sets a file to rw-r----- (owner read/write, group read, others none).
    • 6: Owner = read + write.
    • 4: Group = read.
    • 0: Others = none.
  • umask: Shows the current permission mask applied to newly created files.
  • umask 0027: Sets a stricter default so new files typically become 640 instead of world-readable.
    • 027: Removes write for group and all permissions for others by default.