Back to all posts
Day 27Tuesday, February 24, 20265 min read

Command Resolution, PATH Internals & Shell Environment Investigation

linuxfundamentalscommandlinebashfilesystemlearningprocess
View original post

🎯 Goal

Move beyond simply using commands and understand how the system decides what actually runs when a command is executed.

Focus areas:

  • command resolution order
  • $PATH mechanics
  • filesystem structure
  • environment debugging
  • security implications like PATH hijacking

The objective was to build a first-principles mental model of command execution.

🛠️ What I Did

Explored the Unix filesystem structure

I navigated common directories where executables typically live:

/
 /bin
 /usr
 /usr/bin
 /usr/sbin
 /usr/local/bin

Key realization:

Unix systems organize software by role and responsibility, not by application.

Corrected mistakes with relative vs absolute paths

I initially attempted:

ls bin local sbin

while located at /, which caused lookup errors.

Correct approach:

cd /usr
ls bin local sbin

or explicitly:

ls /usr/bin /usr/local /usr/sbin

Lesson reinforced:

Always confirm current location using:

pwd

before interacting with the filesystem.

Investigated command resolution

When typing a command, the shell checks several possibilities in order.

Observed resolution priority:

  1. Alias
  2. Function
  3. Builtin
  4. Executable located through $PATH

Verification commands:

type -a ls
command -v ls

This revealed that ls was actually an alias on my system:

ls='ls -G'

Which explains why command behavior may differ between environments.

Demonstrated PATH hijacking

To understand how attackers could manipulate command execution, I created a fake executable earlier in the PATH.

mkdir -p ~/bin
printf '#!/bin/sh\necho "FAKE LS"\n' > ~/bin/ls
chmod +x ~/bin/ls
export PATH="$HOME/bin:$PATH"

Running:

ls

executed the fake command instead of the system binary.

This demonstrated how malicious binaries placed earlier in $PATH can override legitimate commands.

The environment was restored afterwards.

Investigated PATH construction on macOS

I printed PATH entries clearly:

echo "$PATH" | tr ':' '\n'

An unexpected entry appeared:

/opt/pmk/env/global/bin

I traced how PATH was constructed by checking:

  • user shell configuration files
  • global shell configuration
  • login shell behavior

I discovered that macOS builds PATH using:

/usr/libexec/path_helper

Further investigation revealed the source:

/etc/paths.d/10-pmk-global

Removing the stale configuration:

sudo rm /etc/paths.d/10-pmk-global
exec zsh -l

Verification with a clean environment:

env -i /bin/zsh -l

confirmed the fix.

Observed terminal session restoration behavior

macOS Terminal can restore previous session environments.

This temporarily preserved outdated PATH values even after configuration changes.

Lesson:

Environment state may persist independently from configuration files.

Testing with a clean login shell is the most reliable validation method.

Built a repeatable command investigation workflow

When encountering unknown commands, I now follow a structured approach:

type -a <command>
command -v <command>
man <command>
file "$(command -v <command>)"
ls -l "$(command -v <command>)"

This allows systematic investigation without immediately relying on internet searches.

🔐 Key Cybersecurity Connections

PATH hijacking

An attacker can place a malicious binary earlier in $PATH so that a trusted command executes attacker-controlled code.

Possible impacts:

  • persistence
  • privilege escalation
  • command interception

Understanding command origin is critical during incident response.

Command execution trust chain

Command execution depends on several system layers:

Shell → PATH → Filesystem → Permissions → Process execution

Security investigations often require tracing activity through this entire chain.

⚠️ Challenges

Several factors initially caused confusion:

  • difference between login shells and active shells
  • terminal session restoration masking configuration changes
  • distinguishing aliases from real binaries

All were resolved by testing in controlled environments.

📚 What I Learned

  • Commands are filesystem objects selected deterministically by the shell.
  • $PATH order directly affects which executable runs.
  • Multiple commands with identical names can exist safely in different directories.
  • macOS dynamically builds PATH using path_helper.
  • Clean login shells are essential for environment debugging.

The biggest realization was that understanding execution flow is more valuable than memorizing commands.

➡️ Next Steps

  • Reinforce the command discovery workflow regularly.
  • Continue learning process inspection tools.
  • Begin exploring networking utilities and log analysis.
  • Strengthen understanding of execution flow in the shell.

🪞 Reflection

This session shifted my perspective on the shell.

Instead of treating commands as simple tools, I began to see the shell as a deterministic execution system that selects programs based on environment rules.

Understanding where commands originate and why they execute builds confidence that directly translates into cybersecurity work.

🧩 Lessons Learned

What worked

  • Hands-on experimentation with the filesystem and PATH
  • Investigating real system behavior rather than relying on assumptions

What broke

  • Expecting environment changes to apply immediately

Why it broke

  • Terminal sessions preserved previous environment state

Fix / takeaway

When debugging shell environments, always validate results using a clean login shell.