“Chown -R root /” quanto sono fregato?

Ho accidentalmente eseguito il comando chown -R root / durante il tentativo di modificare le autorizzazioni per la cartella pubblica della mia app rails. Credevo che questo avesse cambiato le autorizzazioni per tutte le mie cartelle nella directory /. Quindi la mia domanda è: quanto è pericolosa, in effetti la domanda migliore sarebbe, c'è comunque qualcosa da annullare?

Un modo per mitigare il problema qui (non risolvere, ma aiutarti in un buco) è quello di eseguire un processo su un sistema simile per raccogliere le proprietà appropriate per i file. Apprezzo le possibilità che una corrispondenza esatta sia un po 'scarsa, ma se entrambi gli o / s sono allo stesso livello con pacchetti simili installati, potresti essere fortunato.

Una volta raccolti i permessi dei file in un file, è possibile quindi eseguire un processo sul proprio sistema per leggere i file e i permessi / proprietà da quello buono e sostituirli sul proprio. Ho un paio di piccole app cresciute in casa su Linux che fanno proprio questo.

Per esempio

777*0*0*S*16*1334559119*1334532895*1361208513*/usr/lib32/*libgomp.so.1
644*0*0*F*67370*1359536382*1359374461*1359717843*/usr/lib32/*librt.a
644*0*0*F*59044*1334559119*1334532931*1355405098*/usr/lib32/*libgomp.so.1.0.0
644*0*0*F*1238*1359536382*1359374461*1359717843*/usr/lib32/*libBrokenLocale.a
777*0*0*S*17*1359536382*1359374460*1361208513*/usr/lib32/*libdl.so
644*0*0*F*905712*1334559116*1334533011*1355405098*/usr/lib32/*libstdc++.so.6.0.16
777*0*0*S*15*1333306601*1323929512*1361208513*/usr/lib32/*libbz2.so.1.0
777*0*0*S*24*1359536382*1359374460*1361208513*/usr/lib32/*libnss_files.so
644*0*0*F*1128*1359536382*1359374462*1359717843*/usr/lib32/*crt1.o

RWX * UID * GID * altre cose * directory * nome file

Prima di tutto, interrompi il comando se è ancora in esecuzione!

Ora tutto apparterrà alla radice e questo è abbastanza problematico.

Dovresti provare a ripristinare le informazioni dal tuo ultimo backup.

È anche importante non riavviare il sistema prima di controllare tutte le applicazioni in esecuzione e l'utente che le avvia all'avvio. In tal caso, alcuni di essi potrebbero non avviarsi correttamente a causa di problemi con le autorizzazioni.

In bocca al lupo.

Molto e non del tutto.

"Molto", nel senso che se il comando è effettivamente passato, la tua sicurezza è rovinata. Ora non sai quali percorsi hanno quali proprietari e chi dovrebbe essere autorizzato a fare cosa.

"Non del tutto" nel senso: sei sicuro di essere root quando l'hai fatto e il comando è andato fino in fondo? Se l'hai annullato, non appena l'hai visto, potresti essere fortunato e la riparazione potrebbe essere bassa. Se non fossi root, questo comando non avrebbe dovuto essere in grado di farlo, a meno che tu non abbia fatto qualcosa di simile sudo ....

Non esiste un unico rimedio per questo. Se si dispone di un backup, è possibile ripristinarlo. Potrebbe essere necessario controllare le proprietà nel backup e applicarle. Se stai usando un correttore rootkit (diciamo rkhunter), potrebbe avere un elenco delle proprietà più elementari e possibilmente essere in grado di risolverlo. (Non abbastanza probabile).

Almeno su Fedora, il comando RPM ha le opzioni --setpermse --setugids, usando quelle, puoi sistemare la maggior parte dei file di proprietà del sistema come rpm --setugids -a. Per (in qualche modo) riparare i file per ciascun utente, puoi farlo per ognuno chown -R user /home/user. Probabilmente ci saranno degli avanzi che non sono stati corretti da quanto sopra, in particolare se si dispone di una sorta di server (web, ftp, altri), questi dovranno essere gestiti uno per uno.

Probabilmente altre distribuzioni hanno meccanismi simili. Oppure esegui un aggiornamento completo (ovvero installa tutto di nuovo, come se fosse in qualche modo danneggiato. OK, in qualche modo è stato danneggiato.)

[Sì, questo è ancora una volta il modo piuttosto crudele di Unix di insegnare agli utenti ignari di considerare attentamente ogni comando prima di premere INVIO e di usare root con parsimonia . Considerati istruito.]

Se si utilizza OSX apple fornisce una funzionalità di ripristino in Utility Disco per risolvere proprio questo problema. Se stai usando una distribuzione Linux, sono abbastanza certo che dovrai rifare tutte le autorizzazioni manualmente. In entrambi i casi, schiocca le mani e non farlo più

Sfortunatamente non conosco alcun modo per "annullarlo", ma probabilmente puoi lasciare i file di sistema come di proprietà di root e ripristinare tutti i file in $ HOME di tua proprietà (e fare lo stesso per tutti gli utenti del sistema). A quel punto è possibile correggere i permessi e / o il proprietario di ciascun file non presente nella directory $ HOME che ne ha bisogno man mano che si presenta. Sì, questo è un dolore, ma non credo che ci sia una soluzione semplice. Questo è quello che farei comunque.

Direi che sei piuttosto "fregato" come dici tu. Il modo migliore (e più efficiente) è reinstallare e ripristinare gli elementi critici dai buoni backup. Spiacente, questa non è una situazione che generalmente ha una soluzione rapida con un lieto fine. In bocca al lupo!