Ricordiamo che i bit setuid e setgid sono stati inventati per uno scopo completamente diverso:fare in modo che un eseguibile venga eseguito con l'uid o il gid del suo proprietario, piuttosto che con l'uid o il gid dell'utente che esegue il file. Qualsiasi altro utilizzo è solo una funzionalità extra.
Questi bit non hanno alcuna funzione sui file ordinari che non sono eseguibili. (E anche script di shell su alcune distribuzioni, a causa di problemi di sicurezza.) In origine, non avevano alcuna funzione per le directory. Ovviamente qualcuno ha deciso che sarebbe stato bello prendere il setgid inutilizzato nelle directory e usarlo per imporre la coerenza della proprietà del gruppo. Dopotutto, se stai giocando con la proprietà del gruppo, è perché più di una persona sta lavorando con il file e probabilmente ha senso che tutti i file in una data directory appartengano allo stesso gruppo, indipendentemente da chi li ha creati. I problemi dovuti a qualcuno che dimentica di eseguire newgrp vengono eliminati.
Quindi, perché non implementare la stessa funzionalità per setuid e il file uid? Bene, uid è molto più semplice di gid. Se lo implementi, spesso un file non apparterrà all'utente che lo ha creato! Presumibilmente l'utente può ancora modificare il file (supponendo che umask sia qualcosa di sensato), ma non può modificare i bit di autorizzazione. Difficile vederne l'utilità.
Credo che la risposta a questa domanda riguardi i problemi di sicurezza del "file giveaway" che hanno portato la maggior parte dei moderni sistemi operativi simili a Unix a non consentire il "file giveaway". "File giveaway" è quando un utente non superutente cambia la proprietà di un file a qualcuno diverso da quell'utente. Questa capacità offre molte opportunità di malizia.
Poiché i file giveaway non sono consentiti, setuid sulle directory, che svolgerebbero la stessa funzione in un'altra forma, non è consentito o ignorato se impostato.
Per quanto riguarda la modifica del comportamento, dovresti modificare le librerie e le utilità del sistema operativo.
Un ottimo caso d'uso per implementarlo è questo:
Diciamo che hai un server multisito con 3 siti sicuri. Hai creato 3 gruppi, uno per ciascuno dei diversi manutentori del sito. Tutti i file in tutti i siti devono essere di proprietà dell'utente apache in modo che Apache possa leggerli e scriverli (drupal/wordpress, ecc.).
Se il setuid ma funzionasse come il bit setgid per i permessi delle directory sarebbe simile a questo:
/var/www/sitea - apache:groupa rwS rwS ---
/var/www/siteb - apache:groupb rwS rwS ---
/var/www/sitec - apache:groupc rwS rwS ---
In questo modo ogni gruppo di manutentori ha avuto accesso per vedere e toccare solo il proprio contenuto, ma l'utente del server web apache potrebbe servire tutto il contenuto e non è necessario che gli utenti si preoccupino di cambiare la proprietà dei file caricati.
Un altro caso d'uso è per i caricamenti anonimi ftp/http o anche sftp/ssh. Il gruppo e il GID nella directory di caricamento sarebbero root, così come il proprietario e l'UID. Le altre autorizzazioni sarebbero -wx . Ciò consentirebbe a tutti l'accesso WRITE alla directory di caricamento ma non potrebbero leggere nulla una volta che è stato caricato e root sarebbe proprietario di tutti i file appena creati.
Quindi ci sono due casi d'uso perfettamente buoni e validi per abilitare la funzionalità UID sulle directory in modo che corrisponda al bit GID.
Steven Mercurio