Sandbox mount redaction clears caller-owned exceptions in place
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start in redact_mount_error_data and _discard_exception_graph in agents/sandbox/_mount_security.py, then check the same helper in agents.exceptions. Run the reproduction script from the issue to confirm that the saved exception and the one reachable only through __context__ are both emptied. Done means the caller still gets the redacted RuntimeError, the caller's exceptions keep their __dict__, __cause__ and __context__, and the threat-model question about clearing frames is settled by a maintainer decision.
由索引模型根据 Issue 内容生成。
描述
Summary
When a sandbox call fails and its manifest has configured mount authority, redact_mount_error_data replaces the error with a generic RuntimeError. That part works as intended. But before replacing it, _discard_exception_graph mutates the original exception, and every exception reachable from it through __cause__, __context__, args and instance attributes. It clears each one's __dict__ and __cause__/__context__ in place.
Those objects often belong to the caller: an error it saved to raise again, or an unrelated exception it handled earlier that is now in the __context__ chain. After the sandbox call they are empty, so later code that reads them fails in ways that are hard to trace.
Reproduction
Reproduced on openai-agents 0.22.3, 0.23.1 (latest release) and main at 125efa029b4b, with Python 3.13:
import asyncio
from agents.sandbox._mount_security import redact_mount_error_data
from agents.sandbox.entries.mounts import (
InContainerMountStrategy,
RcloneMountPattern,
S3Mount,
)
from agents.sandbox.manifest import Manifest
class AppError(Exception):
def __init__(self, message: str) -> None:
super().__init__(message)
self.message = message
saved = AppError("sandbox start failed")
saved.__cause__ = ValueError("root cause")
held_elsewhere = KeyError("handled earlier, still held by the caller")
held_elsewhere.note = "important"
@redact_mount_error_data
async def start(manifest: Manifest) -> None:
try:
raise held_elsewhere
except KeyError:
raise saved
async def main() -> None:
manifest = Manifest(
entries={
"data": S3Mount(
bucket="b",
access_key_id="AKIA",
secret_access_key="secret",
mount_strategy=InContainerMountStrategy(pattern=RcloneMountPattern()),
)
}
)
try:
await start(manifest)
except Exception as raised:
print("raised: ", type(raised).__name__, "-", raised)
print("saved.__dict__: ", saved.__dict__)
print("saved.__cause__:", repr(saved.__cause__))
print("saved.message: ", getattr(saved, "message", "<missing>"))
print("held_elsewhere.__dict__:", held_elsewhere.__dict__)
asyncio.run(main())
Output:
raised: RuntimeError - sandbox operation failed while using a protected mount configuration
saved.__dict__: {}
saved.__cause__: None
saved.message: <missing>
held_elsewhere.__dict__: {}
Expected: the caller gets the redacted RuntimeError, and saved and held_elsewhere are unchanged.
Actual: both are cleared. held_elsewhere was never raised out of the sandbox call; it is only reachable through __context__.
Impact
We hit this in a Temporal workflow. When sandbox acquisition failed, we saved the temporalio.exceptions.ActivityError and raised it again on later calls, so every call after a failed acquisition failed the same way. The first raise went through BaseSandboxSession.start (decorated with redact_mount_error_data), which emptied the saved object. When we raised it again later, it had no _message or cause, and reading .message raised AttributeError. That error happened in workflow code, so Temporal failed the workflow task and retried it on every replay instead of letting the workflow handle the failure.
Our workaround is to save a detached copy and raise a new copy each time. Any other caller that keeps an exception, or holds one that ends up in a __context__ chain, can hit the same problem.
The same mutation applies to every method decorated with redact_mount_error_data (start, stop, shutdown, aclose, exec, apply_manifest, and others), and to the _discard_exception_graph calls in agents.exceptions.
Suggested fix
The redaction goal can probably be met without mutating objects the SDK doesn't own:
- Raise the safe replacement with no link to the original (
raise safe_error from None, so__cause__isNoneand__suppress_context__isTrue), and drop the SDK's own references to the original. - If frames have to be cleared because locals may hold credentials, clearing the tracebacks (
traceback.clear_frames) may be enough on its own, without also clearing each exception's__dict__and links. - If clearing instance state is still needed, limit it to exceptions the SDK created, or document clearly that any exception reachable from a failed sandbox call may be wiped.
We may be missing a threat-model reason for clearing in place. If so, documenting that behaviour on BaseSandboxSession would still help.
- 主要语言
- Python
- 星标
- 30k
- 派生
- 4.9k
- 平均合并
- 16 小时 25 分钟
- 30 天内合并 PR
- 220
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
openai/openai-agents-python 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 77/100
openai/openai-agents-python#5348 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
openai/openai-agents-python#5353 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 半天 新手友好度 70/100
openai/openai-agents-python#5342 · 3 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 3/5 1-2 天 新手友好度 65/100
openai/openai-agents-python#5336 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
openai/openai-agents-python#5322 · 2 条评论 ·
维护者通常 1 天内回复
查看 openai/openai-agents-python 的全部 Issue
相似的 Issue
-
approved Good First Issue scope: docs
难度 1/5 1 小时以内 新手友好度 85/100
hiero-ledger/hiero-sdk-python#2730 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
wemake-services/wemake-django-template#3178 · 1 个 reaction ·
维护者通常 1 天内回复
-
md/asciidoc/csv: an explicit `encoding="utf-8"` keeps a leading BOM, the auto-detect path drops it未关闭
难度 2/5 1-3 小时 新手友好度 82/100
docling-project/docling#4846 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
neurostuff/NiMARE#1181 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
pytest-dev/pytest#15180 ·
维护者通常 1 天内回复