nah can be bypassed via symbolic links

[Inesteem]

nah's path-based classification does not resolve symbolic links before making decisions. A symlink pointing to a sensitive file bypasses the protection because nah evaluates the symlink path, not the target.

Steps to Reproduce

# Direct access to sensitive file — should be blocked or ask
nah test "cat /etc/shadow"
# Result: filesystem_read → allow (questionable but at least visible)

# Create symlink to sensitive file
mkdir -p /tmp/nah-test
ln -sf /etc/shadow /tmp/nah-test/harmless.txt

# Access via symlink — nah sees an innocent path
nah test "cat /tmp/nah-test/harmless.txt"
# Result: filesystem_read → allow

Expected Behavior

nah should resolve symlinks (via readlink -f or equivalent) before classifying paths, especially for Read/Write/Edit tool calls. At minimum, sensitive path checks should apply to the resolved target, not just the apparent path.

Impact

An LLM agent could create a symlink to ~/.ssh/id_rsa, ~/.aws/credentials, or .env files and then read them through the symlink path, bypassing nah's sensitive path protection entirely.

Suggested Fix

Before classifying, resolve the real path:

import os
real_path = os.path.realpath(apparent_path)
# Then classify based on real_path

This should apply to all tools that take file paths: Read, Write, Edit, Glob, Grep.

[manuelschipper]

Thanks for the report. The /etc/shadow example is actually expected behavior — nah guards user-specific secrets (~/.ssh, ~/.aws, ~/.docker, etc.), not system files. /etc/shadow is unreadable without root on standard Unix systems, so there's no real exposure there.

The core concern — symlinks to sensitive user paths — is already handled. nah uses os.path.realpath() to resolve symlinks before all path checks. Verified across all tools:

ln -sf ~/.aws/credentials /tmp/harmless.txt

nah test --tool Read /tmp/harmless.txt         → ASK (targets ~/.aws)
nah test --tool Write /tmp/harmless.txt        → ASK (targets ~/.aws)
nah test --tool Edit /tmp/harmless.txt         → ASK (targets ~/.aws)
nah test --tool NotebookEdit /tmp/harmless.txt → ASK (targets ~/.aws)
nah test "cat /tmp/harmless.txt"               → ASK (targets ~/.aws)

Chained symlinks (A → B → ~/.aws/credentials) are also caught — realpath() resolves the full chain.

We've added 8 regression tests confirming this behavior across direct, chained, relative, and broken symlinks for all tool types (included in the next release).

Closing as working-as-designed. If you find a specific symlink path that does bypass nah's sensitive path check, please reopen with the exact reproduction — that would be a real bug.

[manuelschipper]

Follow-up: merged PR #54 which adds /etc/shadow to the sensitive path blocklist as a block entry. So the specific example in the report is now also addressed — cat /etc/shadow and symlink variants will be blocked.