Pracowałem wczoraj nad rozwijaniem umiejętności wiersza poleceń i natknąłem się na problem polegający na tym, że kiedy korzystałem z sudo, dostałem komunikat o błędzie z informacją „odmowa zgody”. Jednak kiedy użyłem „sudo su” i zrootowałem, polecenie zadziałało.
Dlaczego sudo nie działało w pierwszej kolejności?
To było:
$ sudo cat > /var/www/info. php
<?php
phpinfo( ) ;
? >
^D
Z wydania Linux Bible 2010 w rozdziale dotyczącym konfigurowania serwera LAMP.
command-line
wdypdx22
źródło
źródło
sudo -s
sięsudo su
.Odpowiedzi:
<,> I >> są używane do przekierowywania wejścia / wyjścia dla poleceń - co jest funkcją zapewnianą przez powłokę (np. Bash). Jeśli więc wpiszesz polecenie takie jak
sudo cat > /var/www/info.php
wtedy, powłoka, która je odbiera jako dane wejściowe, próbuje otworzyć plik/var/www/info.php
i udostępnia ten plik jako standardowe wyjściesudo
polecenia.sudo
Polecenie nie jest nawet świadoma tego, czy jego wyjście idzie do konsoli lub przekierowane do pliku, ponieważ jest to załatwione przez powłokę, która powołuje się na niego.Jeśli powłoka, w której wpisałeś swoje polecenie, jest powłoką logowania lub inną powłoką działającą w terminalu z twoim identyfikatorem użytkownika, to ma takie same uprawnienia jak twój identyfikator użytkownika - nie uprawnienia roota.
Tak więc w twoim przypadku, podczas gdy polecenie cat jest wykonywane jako root,
/var/www/info.php
próba kopiowania jego danych wyjściowych jest wykonywana przez powłokę działającą jako zwykły użytkownik, co zgodnie z oczekiwaniami kończy się niepowodzeniem.Obejściem takich sytuacji jest użycie
tee
polecenia:Spowoduje to zamierzony efekt umieszczenia całego tekstu wprowadzonego w konsoli do ^ D w pliku określonym jako parametr.
Jednym być może niepożądanym efektem ubocznym jest
tee
także echo wyjścia na standardowe wyjście, więc po wpisaniu każdego wiersza i naciśnięciu klawisza entertee
wyświetli jego kopię z powrotem. Aby tego uniknąć, możesz użyć następującego wariantu.Szczegółowe informacje
tee
można uzyskaćinfo tee
na terminalu.źródło
sudo nie działa w przypadku poleceń wymagających uprawnień do zapisu pliku, takich jak:
sudo echo "vm.swappines = 100" >> /etc/sysctl.conf
Wyjaśnia to na stronie podręcznika sudo.
źródło
sudo
. Jak zauważono w odpowiedzi koushika, zachowanie jest dość przewidywalne, spójne i „poprawne” dla modelu uprawnień unix.Problem polega na tym, że część „> foo.txt” jest interpretowana i wykonywana przez interpreter poleceń (powłokę) na długo przed uruchomieniem polecenia sudo. Polecenie sudo nie ma pojęcia, że chcesz przekierować dane wyjściowe do pliku.
Twój interpreter poleceń nie ma uprawnień administratora (ale polecenie sudo w końcu później), więc nie może przekierować wyjścia do foo.txt.
źródło
Innym sposobem rozwiązania tego problemu jest uruchomienie podpowłoki za pomocą sudo i wykonanie tej komendy w tej podpowłoce:
tutaj polecenie „ma sudo” to bash, a cokolwiek w nim wykonane ma uprawnienia root.
2c $ * -pike
źródło