Perché a rm è permesso cancellare un file sotto la proprietà di un altro utente?

Dal post Perché rm può rimuovere i file di sola lettura? Capisco che rmper rimuovere il file è necessaria solo l'autorizzazione di scrittura nella directory. Ma trovo difficile digerire il comportamento in cui possiamo facilmente eliminare un file il cui proprietario e gruppo sono diversi.

Ho provato quanto segue

mtk: il mio nome utente
abc: creato un nuovo utente

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

Stavo pensando che questo non avrebbe dovuto essere permesso. Un utente dovrebbe essere in grado di eliminare solo i file di sua proprietà? Qualcuno può fare luce sul perché questo è permesso? e qual è il modo per evitarlo? Posso solo pensare di limitare l'autorizzazione alla scrittura della directory principale per non consentire cancellazioni di file sorprese.

— MTK
fonte

Risposte:

100

Il motivo per cui questo è consentito è legato a ciò che effettivamente fa la rimozione di un file. Concettualmente, rmil compito è quello di rimuovere una voce dal nome di una directory. Il fatto che il file possa quindi diventare irraggiungibile se quello era il solo nome del file e che quindi l'inode e lo spazio occupato dal file possano essere recuperati a quel punto è quasi casuale. Il nome della chiamata di sistema che il rmcomando richiama, che è unlink, è persino indicativo di questo fatto.

E, rimuovere una voce dal nome di una directory è fondamentalmente un'operazione su quella directory , quindi quella directory è la cosa di cui hai bisogno per avere il permesso di scrivere.

Il seguente scenario può renderlo più comodo? Supponiamo che ci siano directory:

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

E c'è un file che è di mia proprietà e che ha due hard link:

/home/me/myfile
/home/you/myfile

Non importa come quel collegamento /home/you/myfilereale sia arrivato lì in primo luogo. Forse rootmettilo lì.

L'idea di questo esempio è che dovresti essere autorizzato a rimuovere il collegamento reale /home/you/myfile. Dopotutto, sta ingombrando la tua directory. Dovresti essere in grado di controllare ciò che esiste e non esiste all'interno /home/you. E quando lo fai rimuovere /home/you/myfile, avviso di non aver in realtà eliminato il file. Hai rimosso solo un link ad esso.

Si noti che se il bit sticky è impostato sulla directory che contiene un file (si presenta come tin ls), allora si fa necessità di essere il proprietario del file, al fine di essere autorizzati a eliminarlo (a meno che non si possiede la directory). Il bit appiccicoso è di solito impostato /tmp.

— Celada
fonte

Con il bit appiccicoso nella directory, devi essere in grado di modificare il file per poterlo rimuovere. Cioè, se il file appartiene a qualcun altro nello stesso gruppo e il gruppo può scrivere nel file, è possibile rimuovere il file. Corollario: chiunque può rimuovere un file con autorizzazione di scrittura pubblica. (Tutti soggetti a poter modificare la directory, ovviamente.)

— Jonathan Leffler

Forse ti sto interpretando male ma non stai dicendo che posso rimuovere -rw-rw-rw- 1 root root 0 Sep 1 11:11 /tmp/foocome mio normale utente ( /tmpè appiccicoso`) perché mi è permesso di scriverlo? Eppure non posso.

— Celada,

Credo che lo scenario me/ yousi focalizzi più chiaramente se si ipotizza che l'utente (colui che non possiede il file) abbia creato il collegamento. I pronomi sono difficili da usare; diciamo che Al crea /home/al/file1e Bob, che ha eseguito (e forse letto) l'accesso /home/al, collega il file /home/bob/als_file. A Bob dovrebbe essere impedito di rimuovere un link che ha creato? E dovrebbe Al essere autorizzato a cancellare (scollegare) /home/bob/als_filequando non ha accesso in scrittura a /home/bob? Questa strada porta al caos.

— Scott

@JonathanLeffler: Come mostra l'esempio di Scott, no, lo scollegamento e il troncamento non hanno lo stesso risultato netto quando ci sono hard link in gioco.

— Kevin,

@Kevin Penso che il punto sia che se qualcuno ha il permesso di scrivere sul file, quindi può distruggere il contenuto, allora potrebbe anche essere autorizzato a scollegarlo (supponendo che abbia anche il permesso di scrittura sulla directory). Il contrario non si applica: essere in grado di rimuovere il file da una directory non significa che dovrebbe essere in grado di distruggere i contenuti, poiché potrebbero essere accessibili da un'altra directory. Questa è la logica dietro come funziona il bit appiccicoso.

— Barmar,

Per rimuovere un file, devi solo essere in grado di scrivere nella directory in cui si trova il file.

Se non ti piace, puoi impostare il bit "sticky" tramite chmod +t dirse sei su un sistema operativo recente a metà (questa funzionalità è stata introdotta intorno al 1986 in SunOS).

Se ti piace essere più preciso, hai bisogno di un filesystem con un moderno implementatore ACL come ZFS. Gli ACL NFSv4 standard basati su NTFS includono il supporto per autorizzazioni di eliminazione specifiche per file per utente e un'autorizzazione "delete_child" per le directory.

— Schily
fonte

Si noti che per aggiungere il tbit, è necessario possedere la directory. E se possiedi la directory, puoi sempre rimuovere i file indipendentemente dal fatto che il tbit sia impostato o meno. Se colleghi un file alla directory di qualcun altro, dovresti essere preparato affinché qualcun altro sia in grado di rimuoverlo. Un'alternativa sarebbe prima di creare una tua sottodirectory e aggiungere invece il tuo file lì, poiché il proprietario non sarebbe in grado di rimuovere quel sottodiride se non è vuoto.

— Stéphane Chazelas,

Descrivi la situazione in modo fuorviante. Tecnicamente, un file non si trova in una directory; piuttosto, un nome per un file si trova nella directory ed rmè un'operazione sulla directory, non sul file. Un file viene rimosso quando viene rimosso l'ultimo riferimento ad esso, ma tecnicamente, questo è un effetto collaterale.

— reinierpost,

La logica è simile a quella di una casa: il proprietario o l'inquilino decide quali ospiti buttare via, indipendentemente da chi li possiede. Inoltre, l'ospite sfrattato che è il benvenuto in un'altra casa (ha un altro collegamento nella directory di qualcun altro) non si congelerà all'esterno.

— rackandboneman
fonte