Chi può modificare le autorizzazioni di un file / directory?


14

Credo (non sono sicuro) che il proprietario di un file / directory e l'utente root siano gli unici utenti autorizzati a modificare le autorizzazioni di un file / directory. Sono corretto o ci sono altri utenti che possono modificare le autorizzazioni?

Risposte:


19

Solo il proprietario e root(superutente) sono autorizzati a modificare l'autorizzazione di un file o directory. Ciò significa che il proprietario e il superutente possono impostare le autorizzazioni read ( r), write ( w) ed execute ( x). Ma è consentito solo modificare la proprietà (utente / gruppo) di file e directory con i comandi chown/ .chgrproot


19
Il proprietario di un file può modificare la proprietà del gruppo di quel file se l'utente è membro del nuovo gruppo.
Kusalananda

7

Ai fini del normale funzionamento, solo root e il proprietario possono farlo chmod. Inoltre, root può chowne chgrp, e inoltre, il proprietario può chgrpfintanto che il proprietario è un membro del gruppo target.

Per motivi di sicurezza, esiste un altro caso: qualsiasi utente con autorizzazione in scrittura alla directory contenente il file può sostituire il file con una copia e quindi diventare il proprietario, acquisendo la possibilità di modificare autorizzazioni e contenuti.

Così:

14:14 mybox:~ mkdir mydir
14:14 mybox:~ cd mydir/
14:14 mybox:mydir echo foo | sudo tee yourfile
foo
14:14 mybox:mydir ls -ld . yourfile 
drwxr-xr-x  3 me    staff  102 Apr 11 14:14 .
-rw-r--r--  1 root  staff    4 Apr 11 14:14 yourfile

Abbiamo creato una directory e scritto un file come root. Poiché root possiede il file, non possiamo scrivere su di esso, né possiamo chmod:

14:15 mybox:mydir echo bar > yourfile 
-bash: yourfile: Permission denied
14:15 mybox:mydir chmod a+x yourfile
chmod: Unable to change file mode on yourfile: Operation not permitted

Tuttavia, abbiamo l'autorizzazione di scrittura per la directory, quindi possiamo sostituire il file per ottenere la proprietà:

14:15 mybox:mydir mv yourfile yourfile2
14:15 mybox:mydir cp yourfile2 yourfile
14:15 mybox:mydir ls -ld . yourfile 
drwxr-xr-x  4 me   staff  136 Apr 11 14:15 .
-rw-r--r--  1 me   staff    4 Apr 11 14:15 yourfile

E ora che siamo il proprietario, possiamo ovviamente fare quello che vogliamo con quel file:

14:15 mybox:mydir echo bar > yourfile 
14:15 mybox:mydir chmod a+x yourfile
14:16 mybox:mydir cat yourfile
bar

Allo stesso modo, qualsiasi utente con autorizzazione in scrittura a qualsiasi directory nel percorso completo che porta al file può sostituire la struttura della directory da quel punto in poi, acquisendo così la proprietà del file con il nome specificato. La proprietà o le autorizzazioni del file originale effettivo (che abbiamo rinominato in "yourfile2") non sono cambiate, ovviamente.

14:17 mybox:mydir ls -l yourfile2
-rw-r--r--  1 root  staff  4 Apr 11 14:14 yourfile2

Sai se qualche distribuzione Linux supporta funzionalità di sicurezza aggiuntive come Windows? Se mi trovo in Windows, posso impostare l'autorizzazione di eliminazione di un file su negata per impedire l'eliminazione anche quando la directory è permissiva.
Kevin Li,

Molti (la maggior parte?) Versioni di Linux attuali supportano elenchi di controllo di accesso a livello di file, ( getfacl / setfacl) che offrono maggiore flessibilità rispetto alle autorizzazioni di file di stile "classico". La cancellazione dei file in * nix funziona rimuovendo il collegamento al file dalla directory, quindi la rimozione dei file è sempre controllata dalle autorizzazioni della directory; i permessi dei file stessi non svolgono alcun ruolo lì.
Bass

Molto fedele alla filosofia Unix di "tutto è un file". Quindi stai dicendo che una cosa del genere non può essere fatta in Linux?
Kevin Li,

3
@KevinLi Questa risposta non è davvero completa. È possibile impostare il bit sticky su una directory per limitare la capacità dei non proprietari di eliminare o rinominare i file. Vedi questa domanda e le sue risposte: unix.stackexchange.com/questions/79395/… Non è necessario utilizzare ACL o altri schemi.
Andrew Henle,

I filesystem @KevinLi * nix sono molto diversi da quelli di Windows. I file esistono separatamente dalla gerarchia di directory e possono avere diversi "collegamenti fisici" che li puntano nelle directory. L'eliminazione di un file in realtà significa la rimozione del collegamento reale, che viene fatto nella directory. Il file tiene traccia del numero di hard link che puntano ad esso e il file effettivo rimarrà sul disco fintanto che esiste almeno un hard link che lo punta. Così, la cancellazione è controllata dai permessi di directory, che fare una speciale opzione per consentire solo le eliminazioni dal proprietario del file e della radice, come dice Andrew.
Bass

1

Il chmodcomando richiama abbastanza direttamente la chiamata di sistema con lo stesso nome; la pagina man per la chmod(2)chiamata di sistema (su Linux 4.10) dice:

L'UID effettivo del processo di chiamata deve corrispondere al proprietario del file oppure il processo deve essere privilegiato (Linux: deve avere la CAP_FOWNERcapacità).

Se il processo di chiamata non è privilegiato (Linux: non ha la CAP_FSETIDcapacità) e il gruppo del file non corrisponde all'ID del gruppo effettivo del processo o a uno dei suoi ID di gruppo supplementari, il S_ISGIDbit verrà disattivato, ma questo non causerà la restituzione di un errore.

Quindi sì, un processo in esecuzione come root può modificare le autorizzazioni di qualsiasi file se non ne è stata eliminata la CAP_FOWNERcapacità.


Anche di interesse è chown; la pagina man per chown(2)dice:

Solo un processo privilegiato (Linux: uno con la CAP_CHOWNcapacità) può cambiare il proprietario di un file. Il proprietario di un file può modificare il gruppo del file in qualsiasi gruppo di cui quel proprietario è membro. Un processo privilegiato (Linux: with CAP_CHOWN) può cambiare il gruppo arbitrariamente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.