Bug or feature? Handling of $var is different to ${var}
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- bash, c
- 領域
- cli, operating-systems
調査の方向性
Start with the parse_args escape handling in src/parse_args.c around lines 626–634, then compare the arguments passed to the shell for $var and ${var} using the reproductions in the issue. Check the relevant sudo tests for argument escaping and add coverage that captures the intended behavior. Done means the behavior is defined and tested so upgrades do not unexpectedly change how these forms are passed to the shell.
索引モデルが issue の本文から書いたものです。
説明
I'm not sure if it is bug or a feature, but if you try to execute a command in a login shell, then the behavior when using $var and ${var} is different (which is unusual).
To replicate execute:
$ sudo -i bash -c '(export var=/etc; cd $var; pwd)'
/root
$ sudo -i bash -c '(export var=/etc; cd ${var}; pwd)'
/etc
In our case we are glad that ${var} is working as expected, i.e. is is NOT expanded before, so that cd would change into /etc in this example.
I guess the reason is the escape handling in parse_args in src/parse_args.c:
As the $ is not being escaped but the { and } (is not alnum), the resulting arguments passed to the shell are different, which can also be verified in the debug log:
Sep 20 14:48:40 sudo[9839] -> sudo_execve @ ./exec_common.c:184
Sep 20 14:48:40 sudo[9839] exec /bin/bash [-bash --login -c bash -c \(export\ var\=\/etc\;\ cd\ $\{var\}\;\ pwd\;\ env\|grep\ SUDO_C\)] [HOSTNAME=
...
Sep 20 14:51:08 sudo[10689] -> sudo_execve @ ./exec_common.c:184
Sep 20 14:51:08 sudo[10689] exec /bin/bash [-bash --login -c bash -c \(export\ var\=\/etc\;\ cd\ $var\;\ pwd\;\ env\|grep\ SUDO_C\)] [HOSTNAME=
The main question here is, is this a bug or a feature? We are using the ${var} variant in tons of productive workflow environments and we don't want to fall into a trap, once the behavior get changed and we are updating to a newer version.
Environment details:
- sudo version: 1.8.23
- OS: RHEL 7.9 running in AWS (same behavior can be seen in ubuntu 22.04 and others)
Thanks, Christian
- 主要言語
- C
- スター
- 1.7k
- フォーク
- 306
- 平均マージ
- 1日 8時間
- マージ済み PR（30日）
- 24
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
sudo-project/sudo のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
sudo-project/sudo#583 ·
メンテナーはふだん 1 日以内に返信
-
Signal forwarded to the command is lost when it arrives between fork() and execve() of the commandオープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
sudo-project/sudo#566 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 52/100
sudo-project/sudo#553 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
sudo-project/sudo#552 ·
メンテナーはふだん 1 日以内に返信
-
Documentation text overflows container instead of wrapping再び着手できるかも @BittuBarnwal7479 が 130 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 58/100
sudo-project/sudo#547 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
sudo-project/sudo の issue をすべて見る
似ている issue
-
vim.filetype.match() prefixes a URL buffer name with the cwd before passing it to filetype functionsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
メンテナーはふだん 1 日以内に返信
-
stream_curl: retry_count never resets after a successful reconnect, so long sequential streams die after 5 drops対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
mpv-player/mpv#18728 ·
メンテナーはふだん 1 日以内に返信
-
followup Prio 📌
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
cyrusimap/cyrus-imapd#6640 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 60/100
メンテナーはふだん 1 日以内に返信