allowedpaths: .. path segments are collapsed lexically, not resolved through symlinks

Open
#561 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
go
Domain
cli, security

Research direction

Start in allowedpaths/sandbox.go, focusing on toAbs and resolve and how every builtin uses them. Reproduce the behavior with a symlinked intermediate component and .., then trace the current lexical path handling. Done means paths are walked component-by-component with symlinks resolved before .., preserving kernel semantics across the affected builtins.

Written by the indexing model from the issue text.

Description

Describe the bug

toAbs (allowedpaths/sandbox.go) resolves relative paths via filepath.Join(cwd, path),
which lexically collapses .. segments before any filesystem/symlink resolution happens.
This diverges from POSIX/kernel path walking, which resolves .. against the resolved
location after following any preceding symlink component.

Reproduce

ln -s /tmp/outside /tmp/sandbox/link
cat link/../file # reads /tmp/sandbox/file, not /tmp/outside/file as GNU cat/the kernel would

Confirmed the same behavior on cat and rm; likely affects every builtin that resolves
a path through the sandbox (ls, echo redirection, etc.), since they all share toAbs/resolve().

For rm this doesn't create a cross-sandbox deletion risk in the case tested (it targets
the in-sandbox file, not the one outside), but the general divergence from real path
resolution semantics could matter for other commands or attack scenarios involving
symlinked intermediate components followed by ...

Fixing this properly means reworking path resolution in allowedpaths to walk ..
against the filesystem component-by-component (resolving symlinks as it goes) rather
than lexically collapsing the whole path up front — a cross-cutting change affecting
every builtin, not a single-command fix.

Originally raised via Codex review on #556: https://github.com/DataDog/rshell/pull/556#discussion_r3623057327

Dominant language
Go
Stars
31
Forks
3
Avg merge
1d 12h
Merged PRs (30d)
11

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DataDog/rshell

All issues in DataDog/rshell

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.