Improved support for changing symlink permissions
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- rust
- Lĩnh vực
- operating-systems
Hướng nghiên cứu
Bắt đầu với cap-primitives/src/rustix/linux/fs/procfs.rs và lần theo cách triển khai fs::set_permissions, đặc biệt là AT_NOFOLLOW_SYMLINK và hành vi của fchmod được mô tả trong issue. Điều tra cơ sở lý do an toàn đã nêu và các nền tảng Unix liên quan, sau đó xác định liệu có thể hỗ trợ việc thay đổi quyền của symlink mà không làm thay đổi ngữ nghĩa mặc định hiện tại hay không. Công việc được xem là hoàn tất khi API và phạm vi đã được quyết định, đồng thời hành vi đối với trường hợp sử dụng trích xuất zip đã được làm rõ.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hello 👋,
I'm trying to implement some logic that extracts a zip file using cap-primitives and ran into a snag with how fs::set_permissions is currently implemented. In the general UNIX implementation it says even AT_NOFOLLOW_SYMLINK with fchmodat is not enough because it would modify the symlink itself, and that it is undesirable behavior. So, because of that, its implemented as a regular fchmod. Its not clear to me why this is undesirable at a glance though.
In my case however, I am actually trying to change the symlink itself based on permission bits that come from the zip file and the current behavior makes that impossible as it always dereferences the symlink and changes the permissions of the linked item instead. This is an odd use case, but I have the constraint of the process umask set at startup being more restrictive then what the zipped file permissions are, so I need to change everything written out to disk after writing to get the correct resulting permissions.
Is this a feature that you would consider adding to cap-primitives, or is "weird" symlink handling something that's considered out-of-scope?
- Ngôn ngữ chính
- Rust
- Star
- 821
- Fork
- 59
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
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 bytecodealliance/cap-std
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
bytecodealliance/cap-std#427 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
bytecodealliance/cap-std#416 · 2 bình luận ·
-
Archiving cap-std Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
bytecodealliance/cap-std#426 · 2 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 45/100
bytecodealliance/cap-std#423 · 5 bình luận ·
-
Replace cap-async-std Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 42/100
bytecodealliance/cap-std#408 · 4 bình luận · 2 reaction ·
Tất cả issue của bytecodealliance/cap-std
Issue tương tự
-
Replayed reasoning items send "content": null, which the Responses API schema does not permit Đang mởbug CLI custom-model
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
rust-bitcoin/rust-bitcoin#6930 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
fulcrumgenomics/ferro-hgvs#2251 ·
-
Missing examples for `Allocator` Đang mởA-allocators A-docs C-enhancement T-libs
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100