Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Improved support for changing symlink permissions

Aperta
#283 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

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

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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bytecodealliance/cap-std

Tutte le issue di bytecodealliance/cap-std

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.