Il sottosistema Microsoft Interix Unix (ora ritirato) per il suo kernel NT gestiva in modo leggermente diverso le autorizzazioni utente e di gruppo rispetto ad altri:
Le informazioni su utenti e gruppi sono archiviate nel database di accesso di sicurezza . Sia gli utenti che i gruppi sono memorizzati nello stesso database, ma i nomi dei gruppi e degli utenti devono essere univoci; nessun gruppo può avere il nome di un utente e viceversa. (Questo database sostituisce i file /etc/passwde /etc/groupsin UNIX.) Gli utenti e i gruppi vengono creati utilizzando la metodologia Windows appropriata (User Manager, Utenti e computer di Active Directory o Utenti e gruppi locali) o con il net usercomando Win32 . (Gli script di shell di esempio per creare e rimuovere utenti sono inclusi nella directory /usr/examples/admin.) Gli utenti possono appartenere a molti gruppi.
Ecco alcuni estratti manuali più specifici:
In Windows, un utente o un gruppo possono possedere un oggetto. Ciò è diverso da UNIX, in cui solo un utente possiede un oggetto.
Windows identifica internamente tutti gli utenti e i gruppi utilizzando un identificatore di sicurezza (SID) . Un algoritmo di hashing genera valori SID unici; nessun due utenti o gruppi avranno lo stesso SID.
Gli utenti e i gruppi che dispongono dell'autorizzazione per accedere a un oggetto sono identificati dal loro SID. Tutti gli oggetti che possono essere protetti da Windows dispongono di un elenco di controllo di accesso discrezionale (DACL), che consiste in voci separate chiamate voci di controllo di accesso (ACE). Un ACE include due importanti informazioni: un SID utente o di gruppo e una descrizione di quanto accesso ha il singolo utente o gruppo a un oggetto.
chgrp
... Modifica l'ID del gruppo per il file ... l'utente che richiama chgrp (1) deve appartenere al gruppo specificato ed essere il proprietario del file o disporre dei privilegi appropriati.
CHOWN
... Gli operandi del proprietario e del gruppo sono entrambi opzionali; tuttavia, è necessario specificarne uno. Se viene specificato l'operando di gruppo, deve essere preceduto da due punti (:).
Il proprietario può essere specificato da un ID utente numerico o da un nome utente. Se un nome utente è anche un ID utente numerico, l'operando viene utilizzato come nome utente. Il gruppo può essere un ID gruppo numerico o un nome di gruppo. Se il nome di un gruppo è anche un ID numerico di gruppo, l'operando viene utilizzato come nome di gruppo.
Per motivi di sicurezza, la proprietà di un file può essere modificata solo da un processo con privilegi appropriati.
Come ho letto, ciò significa che se il tuo account utente appartiene a un gruppo di Windows con privilegi sufficienti per modificare le autorizzazioni di un file di proprietà di quel gruppo, è possibile efficacemente chgrpquel file al di fuori del controllo del tuo account utente. Ciò equivale a un controllo minore di quello che potresti avere con parametri chownespliciti user:group. In quel contesto senza la possibilità di dichiarare user: e :group non potresti mai ottenere gli stessi risultati come altrimenti.
Ecco un link a uno sguardo dettagliato su come Interix interagisce con gli ACL di Windows con un focus su come tali conoscenze potrebbero applicarsi ai file system Samba su altre varianti di Unix.
Ecco un link a un documento Solaris ormai obsoleto che descrive il parametro sintonizzabile rstchownche ...
Indica se la semantica POSIX per la chown(2)chiamata di sistema è attiva ...
Apparentemente, se il parametro è impostato su un valore di 0...
... la disattivazione della semantica POSIX apre il potenziale per varie falle di sicurezza. Apre inoltre la possibilità che un utente cambi la proprietà di un file con un altro utente e non sia in grado di recuperare il file senza l'intervento dell'utente o dell'amministratore di sistema.
Tale opzione non invalida la conformità POSIX di Solaris . Solo che è un'opzione lo qualifica come conforme :
Sebbene tutte le implementazioni conformi a POSIX.1-2008 supportino tutte le funzionalità descritte di seguito, potrebbero esserci procedure di configurazione dipendenti dal sistema o dal file system che possono rimuovere o modificare
alcune o tutte queste funzionalità. Tali configurazioni non devono essere effettuate se è richiesta una rigorosa conformità.
Le seguenti costanti simboliche devono essere definite con un valore diverso da -1. Se una costante è definita con il valore zero, applicazioni dovrebbero utilizzare i sysconf(), pathconf()o fpathconf()funzioni, o
getconfutilità, per determinare quali caratteristiche sono presenti nel sistema in quel momento o per la particolare percorso in questione.
_POSIX_CHOWN_RESTRICTED
L'uso di chown()è limitato a un processo con privilegi appropriati e alla modifica dell'ID di gruppo di un file solo con l'ID di gruppo effettivo del processo o con uno dei suoi ID di gruppo supplementari.
La chown()funzione di sistema - che è la chiamata di sistema documentata effettuata da entrambe le utility chowne chgrpshell - viene specificata in modo errato per numerosi motivi. Tra loro:
EACCES
L'autorizzazione di ricerca è negata su un componente del prefisso del percorso.
ELOOP
Esiste un ciclo nei collegamenti simbolici incontrati durante la risoluzione dell'argomento path.
EPERM
L'ID utente effettivo non corrisponde al proprietario del file o il processo di chiamata non dispone dei privilegi appropriati e _POSIX_CHOWN_RESTRICTED indica che è necessario tale privilegio.
Tuttavia, il comportamento di concessione dei diritti di modifica delle autorizzazioni agli utenti non root non è mai stato univoco per Solaris. C'è un'eccellente copertura, seppur datata, delle autorizzazioni per i file Unix in questo post del forum in cui l'autore afferma:
Inizialmente, Unix consentiva al proprietario di un file di distribuire un file. Il proprietario di un file potrebbe cambiare il proprietario in qualcun altro. Non c'era modo per un utente non root di annullare questa operazione ... BSD [successivamente] rimosso chowndagli utenti non root ... [in parte perché] ... implementava quote del disco che potevano limitare quanto spazio su disco un l'utente potrebbe avere in un filesystem ... Gli utenti cattivi potrebbero regalare file di grandi dimensioni per passare oltre le quote.
Oggi, non è facile dire se un non-root può chownun file. Molte versioni di Unix consentono entrambi i comportamenti ...
Un altro buono - e più recente - post di mailing list cita questo e continua:
L'impostazione predefinita con la maggior parte dei SO è chownlimitata al solo root. E c'è un consenso sul fatto che dovrebbe rimanere così per considerazioni di sicurezza. Se un utente non root cambia il proprietario di un file e qualsiasi bit di esecuzione è attivo, i bit SUIDe SGIDdevono essere cancellati. Questo può accadere o meno con root.
Penso che l'ultimo paragrafo lo dica bene.
Quell'articolo fa anche riferimento CAP_CHOWNal controllo di quella struttura su Linux (che dovrebbe influenzare solo il POSIX_CHOWN_RESTRICTEDcomportamento) . C'è anche la CAP_FOWNERcapacità, che è un po 'diversa nel comportamento.
E come fai notare nel 2003 :
Nota che almeno su HPUX, puoi cambiare il proprietario dei tuoi file (ad rootesempio) anche se non sei un utente privilegiato ...
... che dipendeva da un setprivgroupparametro di configurazione .
In ogni caso in cui un utente non root può manipolare i permessi sui file, è concepibile, come è menzionato nella logica citata nella tua domanda, che un utente potrebbe chownun file che possiede in modo che sia di proprietà di un altro utente. Se la proprietà del gruppo del file e i chowngruppi dell'utente ing non si allineano, l'utente non sarebbe più in grado di modificare quel file.
In questo scenario chown quindi chgrp fallirebbe poiché l'utente non avrebbe più le autorizzazioni per modificare le autorizzazioni di quel file, mentre chown user:group- fintanto che il gruppo è tra i propri utenti - avrebbe successo.
Probabilmente ci sono numerose altre situazioni di nicchia che potrebbero risultare in modo simile, che potrebbero includere elenchi di bit appiccicosi e / o setgid , file system e / o liste di controllo accessi specifiche dell'implementazione. Questo thread è interessante, per esempio. Le innumerevoli permutazioni sono molto al di là della mia debole comprensione - motivo per cui questa risposta è sconsiderata. Se stai leggendo questo, ritieni che valga la pena migliorare e ritieni di sapere come fare, per favore .
Esiste anche un'ampia documentazione sui vari possibili effetti dei permessi dei file, della traversata degli alberi e dei collegamenti simbolici che potrebbero provocare un errore simile per quanto riguarda le applicazioni -Recursive chownqui:
Dalle intestazioni delle sezioni POSIX XRAT Terzo e quarto dominio :
Generalmente, gli utenti che specificano l'opzione per un attraversamento della gerarchia di file desiderano operare su una singola gerarchia fisica, e quindi i collegamenti simbolici, che possono fare riferimento a file al di fuori della gerarchia, vengono ignorati. Ad esempio, il file del proprietario del chown è un'operazione diversa dallo stesso comando con l'opzione -R specificata. In questo esempio, il comportamento del comando chown owner fileè descritto qui, mentre il comportamento del chown -Rfile del proprietario del comando è descritto nel terzo e nel quarto dominio.
... Esiste un problema di sicurezza con l'impostazione predefinita di una camminata logica. Storicamente, il chown -Rfile utente del comando è stato protetto per il superutente poiché i bit setuid e setgid sono stati persi quando è stata modificata la proprietà del file. Se la camminata fosse logica, la modifica della proprietà non sarebbe più sicura poiché un utente potrebbe aver inserito un collegamento simbolico che punta a qualsiasi file nella struttura. Ancora una volta, ciò richiederebbe l'aggiunta di un'opzione ai comandi che eseguono l'attraversamento della gerarchia per non indirizzare attraverso i collegamenti simbolici, e gli script storici che fanno passeggiate ricorsive diventerebbero immediatamente problemi di sicurezza. Sebbene questo sia principalmente un problema per gli amministratori di sistema, è preferibile non avere impostazioni predefinite diverse per le diverse classi di utenti.
...
In 4.3 BSD, chgrpdurante l'attraversamento degli alberi è cambiato il gruppo del collegamento simbolico, non il bersaglio. I collegamenti simbolici in 4.4 BSD non avevano il proprietario, il gruppo, la modalità o altri attributi standard del file di sistema UNIX.
E dalla chgrppagina POSIX corretta c'è questo che indica una possibile -Razione ecursiva incompleta , o almeno a quello che era :
Le versioni System V e BSD utilizzano codici di stato di uscita diversi. Alcune implementazioni hanno utilizzato lo stato di uscita come conteggio del numero di errori verificatisi; questa pratica non è realizzabile poiché può traboccare l'intervallo di valori di stato di uscita validi. Gli sviluppatori standard hanno scelto di mascherarli specificando solo 0 e> 0 come valori di uscita.