26

Właśnie uruchomiłem to kilka sekund temu. Udało mi się Ctrl- Cjak tylko zdałem sobie sprawę, co zacząłem robić.

Jak dotąd jedynym katalogiem, przez który zaczął przechodzić, jest /bin.

Boję się zrobić cokolwiek innego. Do tej pory zdałem sobie sprawę, że nie mogę już używać sujako mojego normalnego użytkownika.

Na szczęście nadal mam otwarty inny terminal główny. Co ja robię?

— Wola
źródło

26

Wygląda na to, że zostałeś tam porzucony, kolego.

— ta.speot.is

4

Teraz rozumiesz znaczenie kopii zapasowych. Rób to regularnie.

— Juliano,

Przynajmniej nie chmod z roota. To pełna katastrofa. Przynajmniej rm -rf z katalogu głównego daje więcej miejsca na dysku i przygotowuje cię do pełnej ponownej instalacji systemu, chmod po prostu pozostawia prawdziwy bałagan, z którego ciężko jest odzyskać wszystko oprócz kompletnej ponownej instalacji systemu. Trawa jest brązowa po obu stronach ogrodzenia, co?

— Fiasco Labs,

10

Większość wszystkiego w / bin / powinna należeć do roota: root, więc jeśli uruchomisz poniższe, możesz naprawić własność tych plików:

chown root:root -R /bin/

Możesz także upewnić się, że bit setuid jest poprawnie ustawiony na / bin / su, co możesz naprawić za pomocą:

chmod 4755 /bin/su

— epic9x
źródło

1

W Ubuntu szczególnie ważne jest, aby robić to samo z sudo. Nie sądzę, że hasło roota jest nawet ustawione domyślnie? Nawiasem mówiąc, naprawdę polecam używanie sudo zamiast skorup root. Pół sekundy potrzebnej do wpisania sudo zwykle zatrzymuje błędy na ścieżkach. Po prostu praca w skorupce roota jest łatwiejsza do pominięcia ...

— Bernd Haug

4

paste.ubuntu.com/362468 to „ls -l / bin” z mojego pulpitu Ubuntu 9.10. Chociaż może nie mam zainstalowanych dokładnie takich samych plików jak Ty, powinien on przynajmniej dać ci dobrą wskazówkę, które pliki wymagają specjalnych uprawnień.

— andol

@Bernd: Chociaż nie wykonuję aż tak dużo pracy administracyjnej, zauważyłem, że sudo mam mniej głupich rzeczy niż root. Nie mogę już nigdy użyć hasła roota. (I nie, nie ma domyślnego hasła roota na Ubuntu i nie sądzę, że jest takie hasło na MacOSX.)

— David Thornley

@David: Zdecydowanie nie ma domyślnego hasła roota w systemie OS X, a ustawienie jednego jest w większości błędem, IMO. Jest prawie zawsze inny, lepszy sposób. Problem polega na tym, że komputery Mac nie są zbyt bezpieczne na początek; Spodziewam się, że zobaczę dużo „zabawy”, gdy będą mieli większą bazę instalacyjną, aby zyskać na RK, Virii, kliencie Botnet i inne.

— Bernd Haug,

36

Redhat użytkownik:

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

Użytkownik 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

Podczas działania ekranu wykonaj to co najmniej dwa razy:

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

Zwróć szczególną uwagę na wynik, ponieważ jeśli narzeka on na coś, co ma złe uprawnienia, powinieneś to naprawić w innym oknie ekranu.

Kurs zderzenia na ekranie:

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

Użytkownik systemu Solaris:

Jesteś pieprzony

pkgchk -R / -f -a

zresetuje wszystkie uprawnienia, ale spokój wciąż będzie zepsuty. Użyj kopii zapasowej lub innej maszyny Solaris, aby wyszukać skrypty i pliki setuid / setgid i naprawić je ręcznie.

WAŻNA RZECZ O BACKUPACH

Czy możesz je odzyskać, a nie że je bierzesz.

Inne osoby doradzały ci, jak robić kopie zapasowe, ale chcę dodać, że powinieneś je testować. Jeśli używasz systemu uniksowego, nie ma żadnego powodu, aby okresowo nie zrzucać plików na inny komputer i upewnić się, że wszystko działa.

— geocar
źródło

Użytkownik FreeBSD: nigdy nie popełniłby tego rodzaju błędu;)

— einstiien

10

@einstiien Tak, użytkownicy FreeBSD idą prosto na rm -rfscenę.

— grawity

@grawity: lol, dobry.

— einstiien

Biedni użytkownicy Solaris :(

— Mircea Chirea

3

Należy pamiętać, że flagi set-uid na ewentualnych plikach binarnych również mogły zostać usunięte; jest to funkcja bezpieczeństwa Chown. Sprawdź w innym systemie, które pliki binarne mają flagi set-uid lub set-gid i pamiętaj, aby ustawić je również na swoich plikach binarnych.

— Miś
źródło

3

Chciałem wyjaśnić szczegóły używania RPM do resetowania uprawnień do plików, ale znalazłem witrynę z dużo większą ilością informacji . Wspomina również, że Ubuntu / Debian (ogólnie .debs) nie obsługuje tego.

Ale ogólnie rzecz biorąc, opcja, której szukasz, byłaby taka sama:

rpm --setugids {packagename}

— Coops
źródło

Jest to system Ubuntu, jak wskazują tagi. Oznacza to, że zamiast rpm i .RPM używane są dpkg i .DEB

— Kevin M

2

Gdyby to był system Debian, aptitude przeinstalowałbym wszystko.

— ptman
źródło

0

czy masz działającą kopię zapasową? kiedy tak, przywróć folder bin.

w przeciwnym razie spójrz na inne okno, w którym zainstalowałeś tę samą wersję ubuntu i chownna to, co znajdziesz na działającej instalacji.

— chrześcijanin
źródło

0

spróbuj tego: znajdź wszystkie dane www w katalogu / bin

# find /bin -user www-data

następnie zmień dane www z powrotem na pierwotnego użytkownika

# 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
źródło

0

Dzięki wszystkim za wspaniałe odpowiedzi, wszystko wydaje się teraz naprawione.

/ bin / su zadziałało kiedyś chmod'd na 4755 (nie jestem pewien, dlaczego chown zmienił bit suid)

nie zauważyłem, ale również zaczęło działać w katalogu / home, ale była to łatwa poprawka (wystarczy ustawić user: group dla użytkownika dla każdego katalogu)