Doc/library/tarfile.rst: document that the 'tar' extraction filter does not bound link targets
還沒有人認領這個 Issue。
- 主要語言
- Python
- 星號
- 77.2k
- 分支
- 36k
- 平均合併
- 1 天 9 小時
- 30 天內合併 PR
- 558
描述
Documentation
Documentation
Doc/library/tarfile.rst, the "Extraction filters" section — specifically tar_filter and the 'tar' entry in the filter list.
Summary
The 'tar' extraction filter does not check TarInfo.linkname. A symbolic link member whose target is an absolute path, or a relative path that climbs outside the destination, is extracted as given. Only 'data' refuses such members.
This is deliberate and consistent with PEP 706 — I am not proposing a behaviour change. The problem is that the documentation never states it, and one sentence in the tar_filter description reads as though it does the opposite.
Where the docs mislead
tar_filter's third bullet currently reads:
Refuse to extract files whose absolute path (after following symlinks) would end up outside the destination. This raises
OutsideDestinationError.
The parenthetical "(after following symlinks)" describes os.path.realpath() applied to the member's own destination path — i.e. symlinks that already exist in the destination tree. It reads naturally as "symlink-related escapes are handled here".
That link targets are unchecked is currently derivable only by absence: the reader has to notice that data_filter is introduced with "In addition to what tar_filter does", and that link-target containment appears only in that second list. The non-guarantee is never stated positively, so nobody reading the tar_filter section can learn it from that section.
Why it matters in practice
I found this because five independent projects selected the 'tar' filter (or tarfile.tar_filter directly) in code whose stated purpose is safe extraction, leaving link targets unbounded as a result: unstructured-ingest, container-inspector, portage, poetry, and Samba's python/samba/safe_tarfile.py. Each has been reported to its maintainers separately; I am raising this here because five independent readings landing the same way looks like a docs problem rather than five coincidences.
Samba's case shows the mechanism most clearly, because the comment quotes the docs almost verbatim:
# The 'data' filter preserves no permissions so we select the
# intermediate 'tar' filter here which prevents escape but
# preserves permissions.
extraction_filter = staticmethod(tarfile.tar_filter)
"which prevents escape" is a restatement of the bullet above. That same class's pre-3.12 fallback implements _is_unsafe_symlink() and _is_unsafe_link() by hand — so the module became less strict when it moved to the stdlib filter, which is presumably the opposite of what was intended.
Measurement
Python 3.10.12 on Linux. The harness diffs the destination tree against a pre-extraction snapshot, so a member that was never created cannot be miscounted as written, and it runs with errorlevel=2 so nothing is silently skipped.
CONTROLS -- if these do not pass, nothing below means anything
CONTROL-BENIGN plain file filter=tar -> extracted [ok]
CONTROL-BENIGN plain file filter=data -> extracted [ok]
CONTROL-DOTDOT member path filter=tar -> REFUSED (OutsideDestinationError) [ok]
CONTROL-DOTDOT member path filter=data -> REFUSED (OutsideDestinationError) [ok]
PAYLOADS -- symlink TARGETS
sym -> /etc filter=tar -> LINK CREATED, POINTS OUTSIDE
sym -> /etc filter=data -> REFUSED (AbsoluteLinkError)
sym -> /etc/passwd filter=tar -> LINK CREATED, POINTS OUTSIDE
sym -> /etc/passwd filter=data -> REFUSED (AbsoluteLinkError)
sym -> ../../OUTSIDE filter=tar -> LINK CREATED, POINTS OUTSIDE
sym -> ../../OUTSIDE filter=data -> REFUSED (LinkOutsideDestinationError)
The CONTROL-DOTDOT row is the one that makes the rest meaningful: tar_filter genuinely does close the original CVE-2007-4559 path-traversal case, so "refused" is observable in this harness and the symlink rows are a real difference rather than a broken probe.
Reading through the resulting link works:
read through .../sandbox/lvl1/lvl2/dest/secrets
-> /etc/passwd line 1: 'root:x:0:0:root:/root:/bin/bash'
Stated precisely so the proposed wording is not overclaimed: writing through such a link with a later member in the same archive is refused (OutsideDestinationError), because each member path is re-resolved at extraction time. Under 'tar' this is link placement and file read, not arbitrary write. Hard links to absolute outside paths failed here for an unrelated reason (ExtractError during link-target resolution), so I make no claim about them — the wording below covers symbolic links, which is what I measured.
Proposed change
Two edits, no behaviour change:
- In the filter list, the
'tar'entry gains one clause, since that list is where the choice between'tar'and'data'is actually made:
* the string ``'tar'``: Honor most *tar*-specific features (i.e. features of
UNIX-like filesystems), but block features that are very likely to be
surprising or malicious. This does not include limiting the targets of
symbolic links. See :func:`tar_filter` for details.
tar_filtergains a warning stating the non-guarantee positively:
.. warning::
This filter does not limit where a link member *points*.
:attr:`TarInfo.linkname` is not checked, so a symbolic link whose target
is an absolute path, or a relative path that climbs outside the
destination, is extracted as given.
The rule above constrains where each member is *written*; it does not
constrain where a link resolves to.
Only :func:`data_filter` refuses such members, raising
:class:`~tarfile.AbsoluteLinkError` or
:class:`~tarfile.LinkOutsideDestinationError`.
I have this as a patch and am happy to open the PR. I care that the fact appears somewhere in the tar_filter section — the phrasing is entirely yours to change.
Linked PRs
- gh-156056
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
閱讀 Doc/library/tarfile.rst,重點關注 Extraction filters 區段、tar_filter 以及 'tar' 篩選器項目。根據 PEP 706 和文件中說明的 data_filter 行為,檢視提議的措辭。完成的標準是文件明確說明符號連結的目標不受 tar_filter 限制,同時不改變行為。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- python
- 領域
- documentation
- Issue 類型
- 文件
- 難度
- 1/5
- 預估耗時
- 1-3 小時
- 活躍度
- 停滯
- 描述清晰度
- 描述清楚
- 新手友好度
- 35/100