Special Permissions and ACLs

What you will be able to do

• Explain the five core decisions involved in special permissions and acls.
• Choose the narrow Linux command or method that matches a stated operational need.
• Interpret command output as evidence before deciding whether to change system state.
• Apply an observe, act, verify, and recover workflow to a realistic Linux task.

01

Build the Operating Model

Use setgid directories, sticky behavior, and access control lists only when traditional owner-group-other permissions cannot express the need.

Reliable Linux work separates observation, decision, action, and verification. That order keeps a command from becoming a guess and makes each result useful for the next decision.

Begin in a disposable lab or a recoverable environment. Record the active user, working directory, target, and baseline output before any command that can change system state.

02

Setuid execution

The set-user-ID bit can make an executable run with the file owner's effective user identity. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Identify the specific executable and owner, justify the requirement, and audit behavior before enabling the bit. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: setuid programs expand security impact. You should be able to verify this result: execution can use the file owner's identity.

03

Setgid directories

The set-group-ID bit on a directory makes new entries inherit that directory's group ownership. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Set the shared group, enable setgid, and create a test file to verify inherited group ownership. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: group write still requires suitable mode or acl. You should be able to verify this result: new entries share the directory group.

04

Sticky directories

The sticky bit on a shared directory restricts removal or renaming to appropriate owners and privileged users. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Use sticky behavior for writable shared areas and test with separate accounts before relying on it. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: sticky does not encrypt or hide file contents. You should be able to verify this result: users lack permission to remove unrelated entries.

05

Access ACLs

An access ACL adds named user and group permission entries beyond the traditional three permission classes. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Read the existing ACL, add one narrow entry, and verify the effective permission including the mask. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: the acl mask can limit named entries. You should be able to verify this result: named identity receives explicit access.

06

Default ACLs

A directory default ACL supplies inherited access ACL entries for newly created children. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Set both access and default intent, create sample children, and inspect their resulting ACLs. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: existing children are not changed retroactively. You should be able to verify this result: new children receive planned acl entries.

07

Apply One Controlled Change

Start from the read-only commands that reveal identity, scope, and current state. Write the expected result before entering a modifying command, including which files, processes, accounts, or connections may be affected.

Make one narrow change and stop. If the output reports an error or an unexpected target, preserve that evidence and return to inspection instead of adding unrelated commands.

Repeat the original observation after the action. A successful command status is useful, but the real completion signal is the intended state plus the absence of an unintended side effect.

08

Complete the Evidence Loop

A good terminal record answers four questions: what was observed, why one action was selected, exactly what changed, and how the result was verified. A screenshot without command context answers fewer questions than saved text output.

Test both the expected success and one safe failure condition. This confirms that the procedure recognizes a wrong path, missing permission, invalid input, stopped service, or unavailable endpoint instead of silently continuing.

Finish by restoring the lab baseline when the task was experimental. For an operational change, record the final state and the reversal step so later work begins from a known boundary.

09

Recap Before Practice and Prove

The first decision concerns setuid execution. Identify the specific executable and owner, justify the requirement, and audit behavior before enabling the bit.

The second decision concerns setgid directories. Set the shared group, enable setgid, and create a test file to verify inherited group ownership.

The third decision concerns sticky directories. Use sticky behavior for writable shared areas and test with separate accounts before relying on it.

The fourth decision concerns access acls. Read the existing ACL, add one narrow entry, and verify the effective permission including the mask.

The final decision concerns default acls. Set both access and default intent, create sample children, and inspect their resulting ACLs. Keep the final output as the baseline for the next task.