Perché Linux / POSIX hanno lchown ma non lchmod?

Sembra che Linux supporti la modifica del proprietario di un collegamento simbolico (es. lchown) Ma la modifica della modalità / autorizzazione di un collegamento simbolico (es. lchmod) Non è supportata . Per quanto posso vedere, ciò è conforme a POSIX. Tuttavia, non capisco perché uno dovrebbe supportare una di queste operazioni ma non entrambe. Qual è la motivazione dietro questo?

linux permissions posix

— Florian Brucker
fonte

Le autorizzazioni di un collegamento simbolico sono sempre lrwxrwxrwx. A chmodnon ha senso qui. Seguire il collegamento conduce alle autorizzazioni target.

— ott--

@ott: su Linux, le autorizzazioni di un collegamento simbolico sono sempre quelle che hai dato proprio perché Linux non supporta lchmod. Ma altri sistemi operativi simili a Unix lo supportano (ad esempio Mac OS X ), quindi la domanda è perché Linux non lo fa quando supporta lchown.

— Florian Brucker,

Risposte:

Linux, come la maggior parte dei sistemi simili a Unix (Apple OS / X è una delle rare eccezioni), ignora le autorizzazioni per i collegamenti simbolici quando si tratta di risolvere i loro obiettivi, ad esempio.

Tuttavia, la proprietà dei collegamenti simbolici, come altri file, è rilevante quando si tratta dell'autorizzazione per rinominare o scollegare le loro voci in directory che hanno il tbit impostato, come /tmp.

Per poter rimuovere o rinominare un file (collegamento simbolico o meno) /tmp, devi essere il proprietario del file. Questo è uno dei motivi per cui potresti voler cambiare la proprietà di un collegamento simbolico (per concedere o rimuovere l'autorizzazione a scollegarlo / rinominarlo).

$ ln -s / /tmp/x
$ rm /tmp/x
# OK removed

$ ln -s / /tmp/x
$ sudo chown -h nobody /tmp/x
$ rm /tmp/x
rm: cannot remove ‘/tmp/x’: Operation not permitted

Inoltre, come menzionato da Mark Plotnick nella sua risposta ora cancellata , le applicazioni di backup e archiviazione devono lchown()ripristinare i collegamenti simbolici ai proprietari originali. Un'altra opzione sarebbe quella di cambiare euid ed egid prima di creare il collegamento simbolico, ma ciò non sarebbe efficiente e complicherebbe le giuste gestioni nella directory in cui viene estratto il collegamento simbolico.

— Stéphane Chazelas
fonte

Non sono sicuro se questa sia la motivazione originale, ma fornisce un motivo per cui il design è utile. Grazie!

— Florian Brucker,

Non esiste lchmod () in posix ma fchmodat () che consentirebbe di impostare le autorizzazioni di un collegamento simbolico. Ciò non richiede ancora la valutazione delle autorizzazioni dei symlink.

— Schily
fonte

OP sa che non averlo lchmodè conforme a POSIX. Cosa aggiunge questa risposta che non è già nella domanda?

— muru,

L'op ha chiesto perché è supportata solo una delle funzioni e ho spiegato che praticamente entrambe sono disponibili, ma non sotto il nome indicato.

— schily

Come mai? Lo standard dice : Alcune implementazioni potrebbero consentire di modificare la modalità dei collegamenti simbolici. Questo non è supportato dalle interfacce nelle specifiche POSIX. I sistemi con tale supporto forniscono un'interfaccia chiamata lchmod (). Per supportare tali implementazioni fchmodat () ha un parametro flag. Tutto ciò dice che esiste un flag per fchmodat che consente all'implementazione di modificare i permessi del collegamento simbolico. Non che sia necessariamente possibile.

— muru,

Corretto, poiché i permessi dei collegamenti simbolici non vengono valutati da 35 anni, non ha senso cambiare le modalità. Fchmodat () esiste per ortogonalità. L'unico vero vantaggio era futimensat () poiché i timestamp impostabili per i collegamenti simbolici aiutano gli umani a comprendere un albero di directory.

— schily,

@schilly, OS / X onora le autorizzazioni per i collegamenti simbolici. Lì, se non hai i permessi di lettura, non puoi risolvere i loro obiettivi.

— Stéphane Chazelas,