Linux · Lesson 05

File Ownership & Permissions

Learn how Linux ownership, groups, rwx permissions, special bits, ACLs, directory semantics, and least privilege work together so you can fix access problems without opening the system too far.

Permissions are not just numbers. They describe which identities can read, modify, traverse, or execute a resource. Strong defensive work starts by understanding the user, group, path, service, and required workflow before changing a mode.

Lesson Snapshot

Core concepts6

Special bits3

Inspection commands10

Main goalLeast-privilege access

Learning objectives

Understand the access model before changing it

Explain Linux file ownership, group ownership, and rwx permissions for users, groups, and others.

Read symbolic and numeric permission modes without relying on memorized guesses.

Understand how directories use read, write, and execute permissions differently from regular files.

Recognize when setuid, setgid, and sticky bits are expected, risky, or worthy of investigation.

Use inspection commands to understand ownership and permissions before changing them.

Apply narrow permission fixes without breaking required users, services, scripts, or applications.

Core idea

Access should match the role

The objective is not to make every file private. Some files must be readable by services, some directories must be collaborative, and some executables need special privilege behavior. The correct mode is the one that supports the required role with the least access necessary.

Permission risk

Broad fixes can create broader problems

Commands such as recursive chmod or chown can modify hundreds of objects with different intended roles. Fix the smallest confirmed scope and verify dependent users and services afterward.

Permission fundamentals

Six concepts behind Linux access control

Owner

Every file and directory has an owning user. Ownership affects which permission bits apply and often reflects which user or service is responsible for the object.

Group

Every file and directory also has an owning group. Group permissions are a common way to share access without granting access to everyone.

Read

For regular files, read allows content to be viewed. For directories, read allows the directory entries to be listed when other required permissions are present.

Write

For regular files, write allows content modification. For directories, write controls whether entries can be created, renamed, or deleted when combined with execute permission.

Execute

For regular files, execute allows the file to be run as a program or script when other requirements are met. For directories, execute allows traversal into the directory.

Least privilege

Permissions should give users and services only the access required for their role while preserving the functionality the scenario expects.

Reading modes

Symbolic and numeric permissions describe the same access

-rw-r-----640

Owner can read and write; group can read; others have no access.

-rwxr-x---750

Owner has full access; group can read and execute; others have no access.

drwxr-x---750

Directory owner can list, create, delete, and traverse; group can list and traverse; others have no access.

-rw-------600

Only the owner can read and write the file.

drwx------700

Only the owner can access and modify the directory contents.

-rwxr-xr-x755

Owner can read, write, and execute; group and others can read and execute.

4r

read

2w

write

1x

execute

0-

none

Example: 750

7 means 4+2+1: read, write, execute for the owner. 5 means 4+1: read and execute for the group. 0 means no access for others.

Directory permissions

rwx means something different on directories

Read on a directory

Allows directory entries to be listed, but without execute permission you may not be able to access metadata or descend into entries normally.

Write on a directory

Allows creation, deletion, or renaming of entries when execute permission is also available. This can matter even if the file itself is not writable.

Execute on a directory

Allows traversal and access to entries by name. A directory with execute but no read can sometimes allow access to known filenames without allowing a listing.

Parent directories matter

A file can have the correct mode and still be inaccessible because the user cannot traverse one of its parent directories. Usenamei -lwhen the visible file permissions do not explain the problem.

Inspection first

Commands that explain access before you change it

ls -l /path/to/item

Show symbolic permissions, owner, group, size, and timestamp information.

ls -ld /path/to/directory

Inspect the directory itself instead of listing its contents.

stat /path/to/item

Show detailed ownership, numeric mode, symbolic mode, timestamps, inode information, and other metadata.

namei -l /path/to/item

Show permissions and ownership for each component of a path, which is useful when access fails because of a parent directory.

id username

Show the user's UID, primary group, and supplementary groups that may affect access.

getfacl /path/to/item

Display POSIX ACLs when the getfacl tool is installed. ACLs can grant access beyond the basic owner/group/other bits.

find /path -xdev -type f -perm -4000 -print 2>/dev/null

Find setuid files inside a scoped filesystem. Keep searches limited and interpret results before acting.

find /path -xdev -type f -perm -2000 -print 2>/dev/null

Find setgid regular files inside a scoped filesystem for review.

find /path -xdev -type d -perm -0002 -print 2>/dev/null

Find world-writable directories in a scoped area for investigation.

sudo -u username test -r /path && echo readable

Test whether a particular user can read a path without changing permissions.

Search scope matters

Permission searches can produce a lot of output. Start with a relevant directory or filesystem and use-xdevwhen you want to avoid crossing into other mounted filesystems.

Special permission bits

Powerful behaviors that require context

setuid

4000

s on owner execute

On executable files, may cause the process to run with the effective UID of the file owner.

Many legitimate administrative tools use setuid. Unexpected setuid files deserve investigation, not automatic deletion.

setgid

2000

s on group execute

On executable files, may run with the file's group. On directories, newly created entries may inherit the directory's group.

Setgid directories are common for collaborative group workflows. Understand purpose before removal.

sticky

1000

t on others execute

Weak response

Remove setuid from every result.

Better reasoning

Identify the package, expected mode, executable purpose, path, ownership, and whether the file is trusted before changing a privilege mechanism.

Controlled changes

Change only the confirmed access problem

Goal

Change file owner

Example

sudo chown username /path/to/file

Caution

Use only when the desired owner is known. Changing service or package-managed file ownership can break functionality.

Goal

Change owner and group

Example

sudo chown username:groupname /path/to/file

Caution

Confirm both identities and expected access before applying the change.

Goal

Change only group ownership

Example

sudo chgrp groupname /path/to/file

Caution

Useful when group-based collaboration is intended and owner should remain unchanged.

Goal

Set owner read/write only

Example

sudo chmod 600 /path/to/file

Caution

Appropriate only when the file should be private to its owner. Verify dependent services or users do not require access.

Goal

Set owner full, group read/execute

Example

sudo chmod 750 /path/to/directory

Caution

Directory access depends on intended traversal and collaboration requirements.

Goal

Remove world write

Example

sudo chmod o-w /path/to/item

Caution

Symbolic changes can be safer when you want to alter one permission while preserving the rest.

ACLs

Access beyond owner, group, and others

ACLs extend basic permissions

POSIX ACLs can grant or restrict access for additional users and groups beyond the single owner, owning group, and others fields.

ls may show a plus sign

An ls -l mode ending with + can indicate extended ACL information is present.

getfacl shows the detail

When available, getfacl reveals named user and group entries and the ACL mask.

The ACL mask matters

The mask can limit the effective permissions of named users, named groups, and the owning group.

Default ACLs can inherit

Directories can have default ACLs that influence permissions on newly created children.

Do not erase ACLs blindly

Removing ACLs can break legitimate application or collaboration access even if basic rwx bits look simpler afterward.

umask

Default permissions for newly created objects

umask affects defaults

The umask influences which permission bits are removed from the default mode when new files and directories are created.

It is not a permission by itself

umask modifies creation behavior. It does not directly change existing files.

Process context matters

A user's shell, a service, or an application may use different umask settings.

Check before changing

A stricter umask can improve privacy but may break workflows that depend on group-readable or group-writable files.

umask

High-risk permission shortcuts

Fast fixes that often create security or availability problems

chmod -R 777 /some/path

Grants broad read/write/execute access recursively and destroys the intended permission model.

chown -R user:user /system/path

Can break package ownership, service accounts, executable behavior, and application access across a large tree.

Removing all setuid bits

Can break legitimate system tools that rely on controlled privilege elevation.

Fixing access by adding everyone to one group

Expands privilege and file access instead of solving the actual ownership or role problem.

Changing /etc, /usr, or /var recursively

These trees contain many files with intentionally different ownership and permission requirements.

Ignoring parent-directory permissions

A file may look readable while a missing execute permission on a parent directory still blocks access.

Verification

Prove access from the perspective that matters

Mode

Re-run ls -l and stat to confirm only the intended permission bits changed.

Ownership

Confirm the expected user and group own the object after chown or chgrp.

Path access

Use namei -l or a user-context test to confirm every directory component permits the required traversal.

Service

If a service depends on the path, verify the service can still read, write, or execute exactly what it requires.

User workflow

Test the scenario-required user's actual access rather than assuming the mode string guarantees success.

Evidence

Confirm relevant metadata and suspicious permission evidence were recorded before remediation.

Permission success is functional success

A mode string can look correct while the application still fails. Test the real user or service behavior after the change.

Defensive lab

Repair fictional Linux permissions without overcorrecting

Read the fictional scenario: Morgan is the administrator; Avery and Riley share a required project directory; an internal web service reads configuration from /srv/cyberapp but should not rewrite application code.

Inspect ownership and modes for /srv/cyberapp, its parent directories, the shared project directory, and the relevant user home directories.

Use id and namei -l to determine which groups and parent-directory permissions actually control access.

Classify a world-writable configuration file as a confirmed permission problem, but preserve its contents and metadata before changing it.

Correct only the necessary owner/group or permission bits rather than applying recursive 777 or broad chown changes.

Inspect any setuid or setgid findings in the scoped practice directory and determine whether they are expected.

Verify Avery and Riley retain required collaboration access and the web service still functions with least privilege.

Lesson checklist

Before moving on

I can read rwx permissions for owner, group, and others.

I can convert common symbolic modes to numeric values and understand what the numbers represent.

I understand that directory read, write, and execute permissions have different effects than file permissions.

I inspect ownership, group membership, and parent-directory permissions before changing access.

I know what setuid, setgid, and sticky bits do at a high level.

I do not remove special bits simply because they look unusual.

I understand that ACLs can grant access beyond basic owner/group/other permissions.

I know that umask influences new-file defaults rather than existing files.

I avoid recursive chmod or chown changes unless the exact permission model is known.

I verify both security and required functionality after every permission change.

Reflection

Check your reasoning

Question 1

Why can chmod 777 solve an access problem while simultaneously creating a security problem?

Question 2

Why can a user fail to access a readable file when a parent directory lacks execute permission?

Question 3

Why should setuid files be investigated instead of automatically modified?

Question 4

How can ACLs make the output of ls -l incomplete as an access explanation?

Question 5

Why can changing ownership break a service even if the permissions look permissive?

Question 6

What should you test after changing permissions on a directory used by multiple users or a service?

Carry this forward

Ownership and permissions exist to support real identities, services, and workflows. Inspect first, make the smallest justified change, and verify access from the perspective of the user or service that actually depends on the path.

Back to Linux CyberPatriot Hub

← Previous Lesson Next Lesson →