Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Tier-1 gate bypass: has_bash_write_pattern exempts all of 2>, so a truncating redirect classifies as read-only

オープン
  • 何か問題がありますか？
#78 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
57/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
bash, shell
領域
security

調査の方向性

Start with agents/context/lib/safe-commands.sh:1027 and reproduce the listed commands by sourcing the file and calling both predicates. Then inspect the related bats suite and add regression cases distinguishing 2> FILE from 2>&1, including the noted &> case. Done when truncating redirects are detected as writes while fd duplication remains exempt and the security checks pass.

索引モデルが issue の本文から書いたものです。

説明

Summary

has_bash_write_pattern (agents/context/lib/safe-commands.sh:1027) uses:

if echo "$cmd" | grep -qE '[^2>&]>[^>&]|>>'; then

The leading class [^2>&] was evidently meant to exempt the fd-dup idiom 2>&1. It does that —
but it exempts every redirect whose > is preceded by 2, including 2> FILE, which
truncates a real file. The command then reports no-write, and with is_bash_safe_command
also returning safe it passes the Tier-1 active-task gate: a file-truncating write allowed with
no active task.

Repro — measured on bleeding-edge (VERSION 1.7.97), not on a fork

COMMAND                            SAFE      WRITE-PATTERN
bin/fw audit > out.txt             SAFE      WRITE        <- correct
bin/fw audit 2> out.txt            SAFE      no-write     <- BYPASS
bin/fw audit &> out.txt            BLOCKED   no-write     <- see note
bin/fw audit 2>&1                  SAFE      no-write     <- correct
bin/fw audit >> out.txt            SAFE      WRITE        <- correct

Reproduce by sourcing the file and calling both predicates on each string.

Note on &>: it comes back BLOCKED, but not because the write was detected — the write
regex misses it identically. It is blocked by the & separator rule. So the same regex defect is
present for &> and merely masked by an unrelated layer. Fixing the separator rule alone would
expose it.

Why it survived

2>&1 and 2> file differ only after the >, but the exemption is written before it. The
character class tests the wrong side of the operator, so it cannot distinguish a dup from a
truncate. Both the intended exemption and the bypass follow from the same expression.

Suggested direction

Exempt the fd-dup form (a & after the operator), not the fd digit before it — something
of the shape "optional leading fd, > or >>, not followed by &". I have deliberately not
opened a PR: this is a security predicate inside a 74KB file with an extensive bats suite, and the
right fix should land with your own regression cases rather than my guess at them. Happy to open
one if you would like it.

Adjacent, same file, same line

That line is echo "$cmd" | grep -qE .... The producer-into-grep -q shape is the one your own
T-2518 comment in agents/fabric/lib/drift.sh documents as SIGPIPE-prone under
set -euo pipefail — grep -q short-circuits, echo takes SIGPIPE, pipefail surfaces 141.
Here a spurious 141 would read as "no write pattern", failing open on a security predicate.
Not observed firing (the input is short), but it is the same class and worth the herestring.

Provenance

Found while fixing the newline/&/|&/;; segmentation bypass reported in #75 — which
bleeding-edge already fixes independently via T-3223, more thoroughly than the downstream fix
did. This one is still live there.

主要言語
Shell
スター
16
フォーク
6
平均マージ
6時間 24分
マージ済み PR（30日）
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DimitriGeelen/agentic-engineering-framework のほかの issue

DimitriGeelen/agentic-engineering-framework の issue をすべて見る

似ている issue

Shell/Bash の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。