26

L'ho appena eseguito pochi secondi fa. Sono riuscito a fare Ctrl- Cnon appena ho capito cosa ho iniziato a fare.

Finora l'unica directory che è stata avviata è /bin.

Ho paura di fare qualsiasi altra cosa. Finora ho capito che non posso più usare sucome mio normale utente.

Fortunatamente ho ancora un altro terminale di root aperto. Cosa faccio?

— Volontà
fonte

26

Sembra che tu sia diventato famoso lì, amico.

— ta.speot.is il

4

Ora capisci l'importanza dei backup. Fallo regolarmente.

— Juliano,

Almeno non è uscito dalla radice. È un disastro totale. Almeno rm -rf da root ti dà più spazio su disco e ti prepara per una reinstallazione completa del sistema, chmod lascia solo un vero casino da cui è abbastanza difficile recuperare qualcosa oltre a una reinstallazione completa del sistema. L'erba è marrone su entrambi i lati della recinzione, eh?

— Fiasco Labs,

10

Quasi tutto in / bin / dovrebbe essere di proprietà di root: root, quindi se si esegue quanto segue è possibile correggere la proprietà su quei file:

chown root:root -R /bin/

Puoi anche assicurarti che il bit setuid sia impostato correttamente su / bin / su, che puoi correggere con quanto segue:

chmod 4755 /bin/su

— epic9x
fonte

1

Su Ubuntu, è particolarmente importante fare lo stesso con sudo. Non penso che una password di root sia nemmeno impostata di default? A proposito, consiglierei davvero di usare sudo invece di shell root. Il mezzo secondo che serve per scrivere sudo normalmente arresta errori del genere nelle tracce. Solo lavorare in una shell di root è più facile da perdere ...

— Bernd Haug,

4

paste.ubuntu.com/362468 è un "ls -l / bin" dal mio desktop Ubuntu 9.10. Anche se potrei non avere esattamente gli stessi file installati, dovresti almeno darti un buon suggerimento su quali file necessitano di autorizzazioni speciali.

— Andol

@Bernd: Anche se non faccio molto lavoro di amministrazione, ho notato che sudo meno cose stupide di quanto faccio come root. Non potrei mai più usare una password di root. (E, no, non esiste una password di root predefinita su Ubuntu e non credo ce ne sia una su MacOSX.)

— David Thornley,

@David: Sicuramente non esiste una password di root predefinita su OS X e impostarne una è principalmente un errore, IMO. C'è quasi sempre un altro modo migliore. Il problema è che i Mac non sono troppo sicuri per cominciare; Mi aspetto di vedere molto "divertimento" quando avranno una base di installazione più ampia per rendere redditizi i client RK, Virii, Botnet ecc.

— Bernd Haug,

36

Utente Redhat:

chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids

Utente Debian / Ubuntu:

chown 0:0 /bin/*  /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen

Mentre lo schermo è in esecuzione, fallo almeno due volte:

dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
    | xargs apt-get install --reinstall --

Presta molta attenzione all'output perché se si lamenta di qualcosa che ha le autorizzazioni sbagliate, dovresti risolverlo su un'altra finestra dello schermo.

Corso di crash sullo schermo:

Control+A     - command key
Control+A a   - emit a control+A
Control+A n   - next "screen"
Control+A c   - create "screen"

Utente Solaris:

Sei fottuto.

pkgchk -R / -f -a

ripristinerà tutte le autorizzazioni, ma l'impostazione sarà comunque interrotta. Utilizzare un backup o un altro computer Solaris per cercare script e file setuid / setgid e risolverli manualmente.

LA COSA IMPORTANTE SUI BACKUP

È che puoi recuperarli, non che li prendi.

Altre persone ti hanno dato consigli per eseguire i backup, ma voglio aggiungere che dovresti testarli. Se si utilizza un sistema unixish, non vi è alcun motivo per cui non è possibile scaricare periodicamente i file su un altro computer e assicurarsi che tutto funzioni.

— geocar
fonte

Utente di FreeBSD: non commetterebbe mai questo tipo di errore;)

— einstiien

10

@einstiien Sì, gli utenti di FreeBSD vanno direttamente sul rm -rfpalco.

— gravità

@grawity: lol, buona.

— einstiien,

Poveri utenti di Solaris :(

— Mircea Chirea,

3

Essere consapevoli del fatto che anche i flag set-uid su tutti i file binari interessati potrebbero essere stati rimossi; questa è una caratteristica di sicurezza di chown. Verifica con qualche altro sistema quali binari hanno i flag set-uid o set-gid e assicurati di impostarli anche sui tuoi binari.

— Teddy
fonte

3

Stavo per spiegare i dettagli dell'utilizzo di RPM per ripristinare le autorizzazioni dei file, ma ho trovato un sito con molte più informazioni . Indica anche che Ubuntu / Debian (quindi .debs in generale) non lo supportano.

Ma in generale l'opzione che stai cercando sarebbe sulla falsariga:

rpm --setugids {packagename}

— Coops
fonte

Questo è su un sistema Ubuntu, come indicato dai tag. Ciò significa che vengono utilizzati dpkg e .DEB al posto di rpm e .RPMs

— Kevin M

2

Se questo fosse un sistema debian, aptitude reinstallerebbe tutto.

— ptman
fonte

0

hai un backup funzionante? in caso affermativo, ripristinare la cartella bin.

altrimenti, guarda un'altra casella in cui hai installato la stessa versione di ubuntu e chownquello che trovi nell'installazione funzionante.

— cristiano
fonte

0

prova questo: trova tutti i dati www nella directory / bin

# find /bin -user www-data

quindi modificare nuovamente i dati www per l'utente originale

# find /bin -user www-data -exec chown ORiginalUser {} \;

# then change www-data back to oringal group
# find /bin -group www-data -exec chgrp originaluser {} \;

— squillman
fonte

0

Grazie a tutti per le ottime risposte, tutto sembra essere stato risolto ora.

/ bin / su ha funzionato una volta chmod'd su 4755 (non so perché chown abbia cambiato il bit del suid)

non me ne sono accorto, ma ha anche iniziato a funzionare tramite la directory / home ma è stata una soluzione abbastanza semplice (basta impostare utente: raggruppa l'utente per ogni directory)