Hacktoberfest 2026：维护者为十月标记出来的 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 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
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 分钟
30 天内合并 PR
5

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

DimitriGeelen/agentic-engineering-framework 的其他 Issue

查看 DimitriGeelen/agentic-engineering-framework 的全部 Issue

相似的 Issue

更多 Shell/Bash Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。