Perché un utente normale non può "chown" un file?

Perché il chowncomando è solo root? Perché gli utenti non root non possono usare chown per regalare file di loro proprietà?

permissions not-root-user chown

— phleg
fonte

non riesco a capire la tua domanda chown, il comando può essere utilizzato anche da utenti non root

— harish.venkat,

Forse ho sbagliato. Bene, la domanda esatta del mio proffesor era: "Perché il trasferimento di diritti da un utente normale non è consentito nei sistemi UNIX?" ...

— phleg

Penso che la vera domanda sia: perché gli utenti non root possono usare chownper regalare i file che possiedono. (Ho visto i sistemi in cui, a seconda della configurazione del filesystem, puoi farlo.)

— Keith Thompson,

correlati: askubuntu.com/questions/95985/…

— Ciro Santilli 29 改造中心法轮功六四事件

Risposte:

La maggior parte dei sistemi unix impedisce agli utenti di "regalare" file, ovvero gli utenti possono eseguire solo chownse dispongono dei privilegi di utente e gruppo di destinazione. Poiché l'utilizzo chownrichiede la proprietà del file o l'essere root (gli utenti non possono mai appropriarsi dei file di altri utenti), solo root può essere eseguito chownper cambiare il proprietario di un file in un altro utente.

Il motivo di questa restrizione è che la distribuzione di un file a un altro utente può consentire che accadano cose brutte in situazioni non comuni, ma comunque importanti. Per esempio:

Se un sistema ha le quote disco abilitate, Alice potrebbe creare un file scrivibile in tutto il mondo in una directory accessibile solo da lei (quindi nessun altro potrebbe accedere a quel file scrivibile in tutto il mondo), e quindi eseguire chownper rendere quel file di proprietà di un altro utente Bill. Il file verrà quindi conteggiato nella quota del disco di Bill anche se solo Alice può utilizzare il file.
Se Alice regala un file a Bill, non c'è traccia che Bill non abbia creato quel file. Questo può essere un problema se il file contiene dati illegali o comunque compromettenti.
Alcuni programmi richiedono che il loro file di input appartenga a un determinato utente per autenticare una richiesta (ad esempio, il file contiene alcune istruzioni che il programma eseguirà per conto di tale utente). Questo di solito non è un progetto sicuro, perché anche se Bill ha creato un file contenente istruzioni sintatticamente corrette, potrebbe non aver intenzione di eseguirle in questo particolare momento. Tuttavia, consentire ad Alice di creare un file con contenuto arbitrario e averlo preso come input da Bill può solo peggiorare le cose.

— Gilles 'SO- smetti di essere malvagio'
fonte

In un precedente lavoro, ho creato un sistema software che dipendeva dall'impossibilità di distribuire file. Ha usato la proprietà dei file per verificare che una richiesta fosse stata inviata da un determinato utente. Durante l'installazione ha verificato se era consentito distribuire file e, in tal caso, ha rifiutato di procedere.

— Keith Thompson,

Un altro problema più critico è che un utente potrebbe copiarlo /bin/bash, impostarlo e quindi chownsu chiunque lo desideri. Ora hanno accesso alla shell come quella persona.

— Patrick

@Patrick chowncancella sempre i bit setuid e setgid.

— Gilles 'SO-smetti di essere malvagio' il

@Gilles e per una buona ragione ... se potessi copiare un binario della shell da qualche parte puoi accedervi, imposta i bit setuid / gid su di esso e chown su root (o su qualsiasi suo ordine che ti dà 6755/0: 0 perms / proprietà) puoi ottenere il root su quel sistema. Oh, ha mancato il commento di Patrick, esattamente.

— appendiabiti

Ok, ma se possiedo il dir ( drwxr-xr-x ring0 ring0 .) in cui root ha un file regolare ( -rw-r--r-- root root file), perché non posso farlo chown ring0 filedal momento che è permesso farlo, come ring0, cp file x ; rm file ; mv x file(e alcuni facoltativi touch sometime file...)?

— Anello Ø

Su Linux, hai bisogno della capacità CAP_CHOWN per chown. root è concesso tale. Fare riferimento a: http://vouters.dyndns.org/tima/Linux-OpenVMS-C-Implementing_chown.html per le spiegazioni. Se hai intenzione di fornire la funzionalità CAP_CHOWN, crea il tuo codice con libcap-ng o libcap come dimostrato da: http://vouters.dyndns.org/tima/Linux-PAM-C-Pluggable_Authentication_Modules_programming_example.html dove devi semplicemente sostituire CAP_AUDIT_WRITE con CAP_CHOWN.

— user1910461
fonte

+1 per te non devi essere root. Perché non devi più essere root.

— ctrl-alt-delor,

A volte, non è nemmeno necessario CAP_CHOWN: unix.stackexchange.com/questions/399975/… Dalla mia lettura dell'origine del kernel, ogni implementazione del filesystem ha il compito di controllare i permessi per chown. E sembra che con NFS, le autorizzazioni siano controllate sul lato server. E se il server è ... strano ... allora è possibile.

— Mike S,

È possibile avviare il comando ma non funzionerà se non si è root. È facile: immagina un utente che può cambiare un software in utente root. Può aggiungere il bit setuid e, voilà, il ragazzo è root! Quindi, l'uso può aggiungere il bit con chmod, ma nessuna possibilità di cambiare il proprietario dei file.

— Dom
fonte

Non è possibile aggiungere il bit setuid su un file che non si possiede e le implementazioni che consentono di distribuire file cancellano il bit setuid.

— Gilles 'SO- smetti di essere malvagio' il

Penso che il punto della risposta di Dom sia questo: immagina di poterlo fare. Quindi ci sarebbero problemi. Il tuo punto, che non puoi, è corretto. Ma l'OP chiede "perché?" Cancellare il bit setuid è un'altra caratteristica di sicurezza che pone di nuovo la domanda "perché?" Che vorrei quindi fare riferimento alla risposta di Dom: SE un utente potrebbe chown, e SE un utente potrebbe impostare, quindi quella combinazione sarebbe disastrosa. Penso che abbia ragione, anche se manca un po '.

— Mike S,