Dlaczego potrzebna jest sudo bash?

3

Czytałem następujący kod:

$ sudo bash
# cd /home/
# ./gitpull.sh

Dlaczego potrzebuję pierwszej linii, co ona dokładnie robi? Co jeśli właśnie to zrobiłem $ sudozamiast $ sudo bash?

bash shell unix

— David542
źródło

7

Uruchamia powłokę bash jako rootużytkownik poziomu. Potrzebujesz go, ponieważ zwykle zwykli użytkownicy nie mają dostępu/home/

Niebezpieczeństwo tego, co robisz, polega na tym, że znajdujesz się w skorupie roota - dość łatwo możesz zepsuć maszynę.

— hvgotcodes
źródło

Uruchamianie cdw podpowłoce (np. Via sudo) nie jest produktywną operacją ... nie zmieni katalogu dla powłoki wywołującej.

— FatalError

3

Lepiej byłoby zrobić:

$ sudo sh -c 'cd /home; ./gitpull.sh'

Ponieważ polecenia wywoływane jako root zostaną zarejestrowane. Wywołanie powłoki bezpośrednio przez sudo pozwala uniknąć wszystkich korzyści bezpieczeństwa sudo i należy tego unikać.

— William Pursell
źródło

2

Niesławne sudo jest swego rodzaju akronimem dla Superuser Do.

Zasadniczo sprawia, że zwykły użytkownik na krótki czas staje się Super użytkownikiem.

W swoim poleceniu sudo bash faktycznie mówisz Superuser do -> powłoka Bourne'a (bash), która otwiera użytkownika root zalogowanego w powłoce.

Jeśli uruchomiłeś sudo, system operacyjny nie wiedziałby, co robić. Ogólnie rzecz biorąc, po sudo następuje polecenie unix.

— nisdis
źródło

0

sudoumożliwia użytkownikom uruchamianie programów z uprawnieniami bezpieczeństwa innego użytkownika (zwykle superużytkownika lub użytkownika root).
bashuruchamia nową powłokę bash.
Tak więc sudo bashuruchamia nową powłokę bash z uprawnieniami bezpieczeństwa użytkownika root.

— suzanshakya
źródło

0

sudo <shell>, jeśli to działa, zdradza słabą instalację sudo i potencjalną słabość bezpieczeństwa.

sudonie powinien być skonfigurowany tak, aby zezwalał na dowolne polecenia takie jak shell; celem sudojest umożliwienie uwierzytelnionym użytkownikom innym niż root uruchamiania niektórych poleceń jako root, bez znajomości hasła roota.

Jeśli sudo bashjest dozwolone dla dowolnego użytkownika, użytkownik ten jest rootowany po prostu dzięki znajomości własnego hasła.

Jeśli osoba atakująca uzyska hasło do dowolnego konta, które jest w stanie to zrobić sudo bash, osoba atakująca ma w ten sposób uprawnienia root.

Właściwym sposobem na zrobienie tego sudo bash(uzyskanie powłoki roota) jest supodanie hasła roota, a nie własnego.

— Kaz
źródło

Nie rozumiem Jaką szkodę możesz wyrządzić sudo bash(lub sudo su, jeśli o to chodzi), z czym nie mógłbyś zrobić sudo evil-command?

— Dennis

sudopozwala tylko robić rzeczy określone w sudoerspliku. Zapewnia bardzo szczegółową kontrolę, ponieważ możesz dać dostęp tylko do tych programów, do których chcesz mieć dostęp. Jeśli sudo bashjednak na to zezwolisz , przyznajesz powłokę poziomu głównego. Możesz zrobić wszystko, co root może zrobić w powłoce. Robi się wokół zalet sudoi sudoersi w zasadzie sprawia, że użytkownik root.

— Bacon Bits

Dokładnie te szkody, z którymi nie możesz zrobić sudo benign-command. bashjest instancją klasy evil-command. Możesz sudoersdokładnie utworzyć swój plik, aby jedynymi dozwolonymi poleceniami były te, które nie mogą wyrządzić żadnej szkody (lub których potencjał wyrządzenia krzywdy jest w jakiś sposób zawarty) i które nie pozwalają na eskalację uprawnień w zakresie dowolnych działań.

— Kaz

1

Zezwolenie na „sudo bash” dla użytkownika X niekoniecznie pozwala wszystkim użytkownikom w pliku sudoers na uruchomienie bash.

— William Pursell

Nie ma nic złego w sudo bash, kolego. To świetny sposób, aby dostać się do miejsca, w którym możesz szybko wykonać swoją pracę i upewnić się, że wszystkie skrypty logowania zostały uruchomione.

— David Betz

0

Założę się, że sudo bashzamiast sudojest określony na

absolutnie upewnij się, że wywołujesz ./gitpull.shbash, a nie inną powłokę, taką jak tcsh, pdkshlub zwykłą starą sh. Jestem prawie pewien, że linia hashbanga skryptu powinna pozwalać skryptowi na określenie, pod którą powłoką ma być uruchamiany, ale może z jakiegoś powodu został pominięty lub program piszący instrukcje nie chce, abyś na tym polegał.
Uważam, że jeśli zaczniesz bashbez innych argumentów, nie będzie to działało jak „powłoka logowania” i może od tego zależy skrypt.
siła przyzwyczajenia ze strony osoby, która napisała instrukcje (być może pracuje w środowisku wielopowłokowym).
być może autor instrukcji nie jest zbyt zręczny lub ma złe nawyki z innych środowisk.

Również @nisdis ma rację. Zwykły stary sudopo prostu drukuje informacje o użytkowaniu. Ale dlaczego nie użyć su...

— LawrenceC
źródło