Bug in xbps-create when a relative symlink point to an absolute symlink
还没有人认领这个 Issue。
评估
调研方向
Start by running the supplied reproduction script and inspect xbps-create's symlink handling around readlink and realpath. Compare the generated files.plist with the package contents, then verify that the corrected metadata lets xbps-remove remove both symlinks without truncating the target path.
由索引模型根据 Issue 内容生成。
描述
Simple script to reproduce
#! /bin/sh
set -e
PKGVER=bug-1_1
ARCH=x86_64
DESC="Package to show a bug in xbps-create"
DESTDIR=/tmp/bug-1
mkdir -p $DESTDIR/etc/A
ln -s /etc/os-release $DESTDIR/etc/abs
ln -s ../abs $DESTDIR/etc/A/rel
xbps-create --arch "$ARCH" --desc "$DESC" --pkgver "$PKGVER" $DESTDIR
After running this script you'll end up with a badly formed package. Contents are ok:
$ tar tvf bug-1_1.x86_64.xbps
-rw-r--r-- root/root 503 1969-12-31 21:00 ./props.plist
-rw-r--r-- root/root 744 1969-12-31 21:00 ./files.plist
lrwxrwxrwx 0/0 0 2021-11-28 20:06 ./etc/abs -> /etc/os-release
lrwxrwxrwx 0/0 0 2021-11-28 20:06 ./etc/A/rel -> ../abs
But files.plist is wrong:
$ tar xOf bug-1_1.x86_64.xbps ./files.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>dirs</key>
<array>
<dict>
<key>file</key>
<string>/etc</string>
</dict>
<dict>
<key>file</key>
<string>/etc/A</string>
</dict>
</array>
<key>links</key>
<array>
<dict>
<key>file</key>
<string>/etc/A/rel</string>
<key>mtime</key>
<integer>1638140801</integer>
<key>target</key>
<string>lease</string>
</dict>
<dict>
<key>file</key>
<string>/etc/abs</string>
<key>mtime</key>
<integer>1638140801</integer>
<key>target</key>
<string>/etc/os-release</string>
</dict>
</array>
</dict>
</plist>
What is going on I think is:
- the file in destdir
/etc/A/relis a symlink andreadlinkgives../abswhich is understood to be relative since it starts with. - the filename is then canonicalized (using realpath) to
/etc/os-release - since the symlink was thought to be relative, this is expected to be inside destdir
- hence we drop the destdir prefix
/tmp/bug-1, that's 10 characters so/etc/os-releaseminus 10 characters giveslease
This actually bit us in the wip sagemath package. The net result is that those symlinks that are badly reported in files.plistare not removed by xbps-remove.
I've since made a workaround in the sagemath package so this won't affect us, but it'd be nice to fix this logic (whiich is kind of hard to understand), at the very least check that the prefix for the link is indeed the destdir before droping it naively and complain if not.
All of this is affected by whether the canonicalized path is actually an existing file; that's why I chose /etc/os-release which should always exist (if this file is not there, the bug doesn't trigger).
- 主要语言
- C
- 星标
- 1.2k
- 派生
- 152
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
void-linux/xbps 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 68/100
void-linux/xbps#475 ·
-
难度 4/5 3-5 天 新手友好度 45/100
void-linux/xbps#701 ·
-
难度 4/5 3-5 天 新手友好度 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overrides可能已有人在做 @outofsyncrs 于 31 天前认领。 未关闭bug
难度 3/5 1-2 天 新手友好度 45/100
void-linux/xbps#696 ·
-
难度 3/5 1-2 天 新手友好度 52/100
void-linux/xbps#695 · 7 条评论 ·
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
NASA-AMMOS/BSL#355 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
arancormonk/dsd-neo#660 ·
维护者通常 1 天内回复
-
[Bug]: remote-ls --updates reports up-to-date OCI refs because it ignores deployed Alt-id可能已有人在做 @Joao-kouznetz 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
#242 leftovers: dated narrative and shas in the social-features test plan可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
EchoTools/nevr-runtime#264 ·
维护者通常 1 天内回复