Improved support for changing symlink permissions
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- rust
- Ambito
- operating-systems
Direzione di ricerca
Inizia da cap-primitives/src/rustix/linux/fs/procfs.rs e segui l’implementazione di fs::set_permissions, in particolare AT_NOFOLLOW_SYMLINK e il comportamento di fchmod descritto nell’issue. Analizza la motivazione di sicurezza indicata e le piattaforme Unix coinvolte, quindi determina se sia possibile supportare la modifica dei permessi dei symlink senza alterare la semantica predefinita corrente. Il lavoro è completato quando sono stati definiti l’API e l’ambito e quando è stato chiarito il comportamento per il caso d’uso dell’estrazione di zip.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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?
- Lingua principale
- Rust
- Stelle
- 821
- Fork
- 59
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di bytecodealliance/cap-std
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
bytecodealliance/cap-std#427 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
bytecodealliance/cap-std#416 · 2 commenti ·
-
Archiving cap-std Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 15/100
bytecodealliance/cap-std#426 · 2 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
bytecodealliance/cap-std#423 · 5 commenti ·
-
Replace cap-async-std Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 42/100
bytecodealliance/cap-std#408 · 4 commenti · 2 reazioni ·
Tutte le issue di bytecodealliance/cap-std
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
agentic-workflows
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
web-infra-dev/rspack#15847 ·