Jak naprawić sudo po „chmod -R 777 / usr / bin”?

15

Wszedłem chmod -R 777 /usr/bini teraz sudo nie działa.

To mówi sudo must be setuid root.

Niektóre porady online, które mają działać chown root:root /usr/bin/sudo chmod 4755 /usr/bin/sudo.

Po wejściu chown root:root /usr/bin/sudopokazuje opened in readonly modebłąd.

— Manojkumar
źródło

1

Musisz być rootem, aby uruchamiać te polecenia

Manoj Kumar: Czy metoda w moją odpowiedź (która już oznaczone jako zaakceptowane) rozwiązać ten problem dla ciebie? Stałem się przekonanie, że jak Damien Roche i Oli komentowali, ta metoda nie działa właściwie po komenda została pomyślnie zakończona. Jak , musi być setuid root pracy. (Nie jestem pewien dlaczego, ponieważ korzysta z usługi polkit , ale tak jest.) Myślę jednak, że słyszałem, jak inni mówili, że to dla nich zadziałało, co jest ciekawe! Czy nacisnąłeś Ctrl + C przed zakończeniem polecenia chmod? pkexecsudo chmod -R 777 /usr/binsudopkexec777

— Eliah Kagan

Witaj. Ta metoda faktycznie zadziałała dla mnie po tym, jak przypadkowo udało mi się uruchomić sudo chmod -R 777 /usr/bin, ale dopiero po zalogowaniu się na rootkonto.

— iHowell

10

^{Niezależnie od statusu zaakceptowanego, jestem teraz przekonany, że ta odpowiedź jest błędna . (Mam nadzieję, że wkrótce to poprawię, po konsultacji z OP w sprawie akceptacji.) Myślę, że przypominam sobie innych, którzy mówili, że to zadziałało, ale wierzę, że ich problemy były przynajmniej nieco inne. Opisany tu sposób pozostaje cenny w niektórych sytuacjach, w których chmod -R 777 /usr/binjest przerywany znakiem Ctrl+ Club w inny sposób się nie kończy. Ale kiedy już to zrobi, nie pkexecjest już ustawione i nie będzie działać lepiej niżsudo , jak słusznie skomentowali Damien Roche i Oli.}

W systemie komputerowym Ubuntu zainstalowany jest PolicyKit , więc pkexecmożna go użyć do naprawy uszkodzonego sudopliku wykonywalnego lub sudoerspliku . Nie trzeba uruchamiać się w trybie odzyskiwania i nie trzeba uruchamiać z dysku CD na żywo. Nie musisz nawet uruchamiać się ponownie.

W takim przypadku uruchom następujące polecenia:

pkexec chown root:root /usr/bin/sudo
pkexec chmod 4755 /usr/bin/sudo

Zobacz to pytanie, aby uzyskać więcej informacji.

— Eliah Kagan
źródło

9

pkexec must be setuid root! Co za koszmar!

— Damien Roche,

1

Jak zauważa Damien, problem z tym podejściem jest pkexecdokładnie taki sam jak sudo. Zwykle jest setuid i żyje /usr/bin. Przetestowałem to i po prostu to nie działa chmod -R 777 /usr/bin.

— Oli

@DamienRoche, Oli: Przepraszam za nie ustalenie ten sposób szybciej! Oboje macie rację. Nie jestem pewien, dlaczego pkexecmusi działać jako root setuid (czy nie działa on przez demona polkit jak inne procesy nie-setuid?), Ale tego potrzebuje. Skomentowałem to pytanie, aby zobaczyć, czy OP (który to zaakceptował) może rzucić światło na to, co, jeśli w ogóle, jest słuszne lub pomocne w tej odpowiedzi. Dodałem tymczasowy baner na początku tego postu, aby nie wprowadzać w błąd. Jeśli ta odpowiedź będzie nadal istnieć, jej ulepszona forma prawdopodobnie będzie zawierała niektóre informacje obecnie w tym banerze.

— Eliah Kagan

Możesz po prostu użyć su, który znajduje się pod / bin

— FliiFe

@FliiFe Naprawianie uprawnień (lub własności) plików /usr/binwymaga uprawnień roota, ale nie można rootować suna większości systemów Ubuntu, ponieważ logowania root są domyślnie wyłączone. W przeciwieństwie do sudoi pkexec, gdy używasz sudo uzyskania powłoki roota lub polecenia jako root, musisz podać hasło roota, a nie własne. Ale root nie ma domyślnego hasła w Ubuntu (co oznacza, że uwierzytelnianie oparte na haśle dla roota zawsze się nie powiedzie, nie że wprowadzenie pustego hasła byłoby skuteczne). Zobacz RootSudo, aby uzyskać szczegółowe informacje.

— Eliah Kagan

4

Nawet podczas uruchamiania z Live CD / Pendrive, musisz poprzedzić swoją chmodkomendę sudo. Twoje kroki będą wyglądały następująco:

boot z live CD / Pendrive
sprawdź, czy dysk został już automatycznie zamontowany (i gdzie). Jeśli nie, zamontuj go (patrz poniżej)
Użyj, sudo chmod 0755 <path>aby dostosować uprawnienia

Jak dowiedzieć się, gdzie jest zamontowany dysk: w oknie terminala uruchom mount(bez argumentów). Spowoduje to wyświetlenie listy wszystkich zamontowanych urządzeń. Sprawdź typelistę - możesz pominąć wszystko, nie używając „prawdziwego systemu plików” (twój dysk prawdopodobnie używa ext3 lub ext4 - na pewno możesz pominąć takie rzeczy jak proc, sysfs i tym podobne). Jeśli coś brzmi obiecująco (wygląda jak /dev/sda1 on /media/sda1 type ext3), sprawdź jego zawartość za pomocą, ls /media/sda1aby zobaczyć, czy to jest to.

Jeśli to nie jest zamontowany, można skontaktować się z /devwpisami w którym dysk mógł być (używając ls /dev/ |grep '/dev/sdw celu sprawdzenia dostępnych urządzeń; dysk powinien wyglądać /dev/sdaX, /dev/sdbXlub tym podobne - gdzie X oznacza numer). Porównaj to z listą zamontowanych urządzeń. Jeśli go nie ma, spróbuj go zamontować i sprawdź jego zawartość (jak pokazano powyżej). Aby go zamontować, najpierw utwórz punkt montowania, np. sudo mkdir /mnt/mydiskNastępnie spróbuj zamontować urządzenie za pomocą mount /dev/sda1 /mnt/mydiski sprawdź jego zawartość za pomocą ls /mnt/mydisk.

Gdy już tam odpowiedniego dysku, można przejść, aby zmienić uprawnienia z powrotem na usr Reż sudo chmod 0755 /mnt/mydisk/usr.

Teraz nadal możesz mieć problemy, jeśli pierwotnie uruchomiłeś chmodpolecenie rekurencyjnie, używając -Rparametru. W takim przypadku możesz spróbować naprawić każdy wpis ręcznie - lub możesz przejść prosto do nowej instalacji ...

— Izzy
źródło

Próbowałem utworzyć punkt montowania, ale dostałem błąd, który odczytał, że punkt montowania mnt / mydisk nie istnieje, to mój dysk można zastąpić czymś i tylko dla zapisu, mount /dev/sda /mnt/mydiskz którego napisałemroot@Ubuntu:/dev#

— vin

Czy a) utworzyłeś ten punkt montowania (katalog) przed wydaniem komendy mount (jak opisano) oraz b) zadbałeś również o wiodący ukośnik? Próbowaćmkdir -p /mnt/mydisk && mount /dev/sda1 /mnt/mydisk (nie sądzę, żebyś miał partycje włączone /dev/sda, więc musiałeś także przegapić numer partycji. Upewnij się, że podałeś właściwe urządzenie (lub montowanie się nie powiedzie).

— Izzy

1

Myślę, że Mat ma rację, musisz być rootem, aby dodać bit do / usr / bin, ale oczywiście sudo jest zepsute. Jeśli masz hasło roota, możesz użyć go do zalogowania się jako root, a następnie naprawić uprawnienia za pomocą powyższej komendy. Jeśli tego nie zrobisz (a ja też nie), prawdopodobnie najlepiej byłoby:

uruchom komputer z live CD z Linuxem
zrootuj się tam
zamontuj partycję za pomocą powyższego systemu
następnie wyprostuj uprawnienia w tym systemie plików za pomocą terminala.

Root jest zawsze numerem użytkownika 0, więc root w dowolnym systemie może wprowadzać zmiany do rootowania w innych systemach plików.

— John S Gruber
źródło

1

Nie mam dużo wiedzy Ale te kroki rozwiązały mój problem, nawet bez ponownego uruchamiania komputera. Wykonaj następujące kroki:

su root
<enter root password>
cd /usr
chmod -R 755 *

— Manu Mohan Thekkedath
źródło

1

Brakuje przynajmniej polecenia „cd”. Jeśli zrobisz to w ten sposób, wykonasz „chmod” w katalogu domowym dla roota. To pogorszy sytuację.

— Rinzwind

thaks ... zredagowałem moją odpowiedź ... byłem w folderze / usr

— Manu Mohan Thekkedath

2

Działa to tylko wtedy, gdy ustawione jest hasło root, co nie jest domyślną konfiguracją Ubuntu.

— David Foerster,

1

Próbując ustawić uprawnienia dla moich lokalnych skryptów, złamałem uprawnienia sudo i przez pomyłkę zmieniłem własność. Byłem w stanie zmienić własność sudo na root, wykonując następujące czynności:

Krok 1: Przełącz na tryb odzyskiwania Ubuntu . Jeśli nie jesteś świadomy tego procesu, możesz znaleźć odpowiedź tutaj: /ubuntu//a/172346/223901

Krok 2: Po przejściu w tryb odzyskiwania wybierz root - monit o upuszczenie do roota

Krok 3: Wykonaj następujące polecenia

mount -o remount,rw /
chown root:root /usr/bin/sudo
chmod 4755 /usr/bin/sudo
reboot

Poczekaj, aż system uruchomi się normalnie, a zobaczysz własność sudo z powrotem do rootowania.

— ramsudharsan
źródło