capability.LastCap fails when /proc/sys/kernel/cap_last_cap is unavailable
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 50/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- go, linux
- Lĩnh vực
- operating-systems, security
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Go
- Star
- 102
- Fork
- 62
- Merge trung bình
- 6 phút
- Pull request đã merge (30 ngày)
- 2
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của moby/sys
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
devices: ignore .incus-mounts in GetDevicesCó thể đã có người làm @SashaMIT đã nhận 9 ngày trước. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
[userns-remap] Bug: ToHost incorrectly maps non-root container UID to root when it collides with RootPairCó thể đã có người làm @okhowang đã nhận 75 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 74/100
-
user: parseLine silently ignores uid/gid conversion errors, malformed ids parse as 0Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
Issue tương tự
-
[Bug]: message-level cache_control on chat messages is dropped, so Anthropic prompt caching never triggersCó thể đã có người làm @Atharva-Kanherkar đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation good first issue help wanted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
eugenioenko/ttt#1000 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Billionmail/BillionMail#389 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Gentleman-Programming/gentle-ai#5603 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue help wanted v3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
oras-project/oras-go#1621 ·
Maintainer thường phản hồi trong vòng 1 ngày