capability.LastCap fails when /proc/sys/kernel/cap_last_cap is unavailable
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 50/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- go, linux
調査の方向性
Start with the LastCap function in the capability package and the ListSupported path that calls it, both of which read /proc/sys/kernel/cap_last_cap directly. Check how the error propagates, then find a way to determine the last capability without that file, such as probing with prctl. Done means LastCap no longer fails when the file is absent, with a test that simulates the missing file.
索引モデルが issue の本文から書いたものです。
説明
capability.LastCap() returns an error when /proc/sys/kernel/cap_last_cap is unavailable. This can cause callers to fail after entering a rootfs that does not contain a /proc mount.
I encountered this through runc 1.3.4. With an OCI configuration containing mounts: [] and five explicitly empty capability sets, runc create failed 5/5 times with:
open /proc/sys/kernel/cap_last_cap: no such file or directory
The workload was /bin/true, so it did not access /proc. Adding only a private /proc mount made runc succeed 5/5 times. crun and youki accepted the original configuration.
It appears that ListSupported() calls LastCap(), which directly opens /proc/sys/kernel/cap_last_cap and returns the error without a fallback.
I expected capability handling, especially for empty capability sets, not to require this file to exist inside the current rootfs.
Original runc report and full reproducer:
https://github.com/opencontainers/runc/issues/5551
- 主要言語
- Go
- スター
- 102
- フォーク
- 62
- 平均マージ
- 6分
- マージ済み PR（30日）
- 2
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
moby/sys のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
-
devices: ignore .incus-mounts in GetDevices対応中かも @SashaMIT が 9 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
[userns-remap] Bug: ToHost incorrectly maps non-root container UID to root when it collides with RootPair対応中かも @okhowang が 75 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 74/100
-
user: parseLine silently ignores uid/gid conversion errors, malformed ids parse as 0対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
似ている issue
-
Chained slog With calls discard previously bound attributes対応中かも @yuefdev が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
[scanner] TestAgentNowLineStates hard-fails instead of degrading when node is off PATH対応中かも @arteeh が今日担当しました。 オープンagent/scanner ci help wanted kind/test
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
hivecommons/hive#12924 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
Gentleman-Programming/engram#1940 ·
メンテナーはふだん 1 日以内に返信
-
area: go-workers help wanted tech debt
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
[exporter/splunkhec] Oversized metric event causes subsequent valid metrics to be dropped対応中かも @harshkoli1255 が今日担当しました。 オープンbug exporter/splunkhec needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
open-telemetry/opentelemetry-collector-contrib#52142 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信