Bug in xbps-create when a relative symlink point to an absolute symlink
まだ誰も着手していません。
評価
調査の方向性
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 ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 が 30 日前に担当しました。 オープンbug
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
void-linux/xbps#696 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 52/100
void-linux/xbps#695 · コメント 7 件 ·
void-linux/xbps の issue をすべて見る
似ている issue
-
backend
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
BasedHardware/omi#20940 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
kovidgoyal/kitty#10625 ·
メンテナーはふだん 1 日以内に返信
-
Feature Status: Needs Triage
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
メンテナーはふだん 1 日以内に返信
-
docs
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信