Sudo vs root; jakieś rzeczywiste różnice?

44

Pracuję z członkiem wsparcia dla produktu, a on nalega, że ​​muszę być rootem, aby zainstalować serię poprawek, a sudo nie będzie działać; nie podaje powodu, ale wydaje się bardzo mocny w swoich przekonaniach. Przeglądanie superużytkownika Nie mogę ustalić żadnego możliwego powodu, dla którego tak się dzieje, i po potwierdzeniu, gdy uruchamiam:

sudo -l

Dostaję:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

Jak rozumiem, uzyskanie dostępu od zespołu Linux / serwera do bycia rootem nie jest natychmiastowym procesem, więc wolałbym je zainstalować sam.

Czy istnieje jakiś praktyczny powód, dla którego sudo zachowuje się inaczej niż root podczas instalowania oprogramowania na serwerze?

linux sudo root Leśniczy
źródło
2
Myślę, że powinieneś mu to rzucić. Jak pokazali inni, istnieje mnóstwo sposobów na zdobycie roota za pomocą sudo, a jeśli nie jest w stanie podać konkretnego powodu, dla którego sudo jest niewystarczające, to nie ma on nogi, aby się na nim oprzeć.
Garrett,
1
Przychodzą mi na myśl środowisko i podkomendy. Myślę, że Hastur wykonał dobrą robotę ze środowiskiem, a Jayen wykonała dobrą robotę z podkomendami, potokami i przekierowaniami.
jww
2
Garrett ma rację, ale zanim wezmę udział w potencjalnym konkursie na sikanie, zapytam członka wsparcia: czy wypróbowałeś to na dwa sposoby i czy zawiodło to na jeden z tych sposobów? Być może był na drodze do niepowodzenia sudoi skryptów, ponieważ skrypty są obecnie napisane. Jeśli o to chodzi, to odpowiedź SDS' może być bardzo pomocne dla Ciebie: sudo su -.
jww

Odpowiedzi:

34

Zależy to w dużej mierze od sposobu wywołania programu za pomocą sudolub su.
Np. W systemie, w którym aktualnie jestem:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1]

Gdzie [1] = / usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin
Env = Zmienne środowiskowe są resetowane dla 1 i 5, wzięte z $ USER w 2,3,4.

Więc skrypt lub program, który zostanie uruchomiony z innej opcji można zobaczyć różne $PATH, $HOMEjego powłoka może odczytać inny .bashrc, .profilei zmiennych środowiskowych. Czyta plik związany z $HOME. Każdy użytkownik może modyfikować swoje środowisko w inny sposób (zmienne $PATH, .bashrc, .profile, .bash_profile, alias ...). W szczególności użytkownik może mieć w swojej książce inną kolejność katalogów $PATH, w wyniku czego skrypt może wykonać polecenie, np. /home/$USER/binZamiast w ścieżce oczekiwanej od roota.

Możesz uruchomić program pod, sudo -igdy jesteś zalogowany jako root su -, ale możesz mieć inne zachowanie, jeśli uruchomisz go z sudo MyCommandlub z su -c MyCommand.

Od man su:

W części opisowej:
Bieżące środowisko jest przekazywane do nowej powłoki . Wartość $ PATH jest resetowana do / bin: / usr / bin dla zwykłych użytkowników lub / sbin: / bin: / usr / sbin: / usr / bin dla superużytkownika
...
W części opcji:
- , -l , --login
Zapewnij środowisko podobne do oczekiwań użytkownika, gdyby użytkownik zalogował się bezpośrednio .

Od człowieka sudo

-i , --login
Uruchom powłokę określoną przez wpis bazy danych haseł użytkownika docelowego jako powłokę logowania. Oznacza to, że pliki zasobów specyficzne dla logowania, takie jak .profile lub .login, zostaną odczytane przez powłokę. Jeśli podano polecenie, jest ono przekazywane do powłoki w celu wykonania za pomocą opcji -c powłoki. Jeśli nie podano polecenia, wykonywana jest powłoka interaktywna. sudopróbuje przejść do katalogu domowego tego użytkownika przed uruchomieniem powłoki. Polecenie jest uruchamiane w środowisku podobnym do środowiska, które użytkownik otrzyma podczas logowania . Sekcja Środowisko poleceń w podręczniku sudoers (5) dokumentuje, w jaki sposób opcja -i wpływa na środowisko, w którym polecenie jest uruchamiane, gdy używana jest zasada sudoers.

Hastur
źródło
Świetna odpowiedź. Nadal jestem nowicjuszem w Linuksie, ale czy kolejną różnicą jest to, że to, co możesz zrobić, sudomoże być ograniczone przez uprawnienia w pliku sudoers w porównaniu do robienia rzeczy, ponieważ root nie ma tych ograniczeń? Ostatni cytat blokowy może to sugerować, ale jeśli dobrze rozumiem, wydaje się to inną istotną różnicą poza samym środowiskiem (a może ze względu na środowisko?).
fixer1234,
23

Jeśli masz pełny sudodostęp, możesz zacząć rootkorzystać sudo su -, więc punkt bezpieczeństwa jest dyskusyjny.

Rzeczywiście istnieje sposób na rozpoznanie różnicy między programem uruchomionym jako roota programem uruchomionym pod sudo- używając getuidvs geteuid- ale jest to wymyślona sztuczka. Dlaczego system łatek miałby to robić?

sds
źródło
5
Mówiąc o tym su -, może chcieć korzystać z niego sudo -i, aby miał takie samo środowisko, jak podczas bezpośredniego logowania.
Cristian Ciupitu,
2
Jeśli uruchomisz np. sudo myscript, Zachowasz $ PATH i zmienne środowiskowe z powłoki, w której się znajdujesz. Jeśli biegniesz z nim sudo -i myscript, biegnij tak, jakbyś logował się jako root. Zobacz odpowiedź z naszym _zoo połączeń :-) _
Hastur
1
Myślę, że ważne jest, aby zwrócić uwagę, że zmienne środowiskowe mogą nie być ustawione tak samo sudojak przy logowaniu jako root
secretformula
1
@dmanexe: sudo nie oznacza superuser do, to „zmień użytkownika na”. su i sudo mogą służyć do przełączania się na dowolnych użytkowników, a nie tylko superużytkownika. Poza tym nie ma nic pseudo w sudo, naprawdę dostajesz rzeczywisty root podczas uruchamiania sudo, a nie jakieś fałszywe cokolwiek. Zauważ, że magia sudo naprawdę pochodzi z bitowej zgody setuid.
Lie Ryan
2
sds, @CharlesDuffy: Idea, że ​​sudo i su powodują geteuid()i getuid()różnią się od siebie, jest mitem. su i sudo zmieniają zarówno rzeczywisty, jak i efektywny identyfikator użytkownika na identyfikator użytkownika docelowego przed uruchomieniem określonej komendy lub powłoki, z wyjątkiem bardzo nietypowej sytuacji, w której jawnie skonfigurowałeś je tak, aby zachowywały się inaczej. Możesz to zweryfikować (dla sudo), uruchamiając sudo id -ui sudo id -ru(oba pokazują 0), czytając sudo (8) (w obszarze WYKONYWANIE POLECEŃ ) lub pisząc program testowy .
7

Istnieje kilka różnic, jeśli otrzymujesz powłokę root, jak wskazał @Hastur.

Jeśli nie otrzymujesz powłoki roota, istnieje więcej różnic. Element nośny może mieć doświadczenie staramy się robić takie rzeczy jak sudo patch -p0 < /root/patch.filegdzie patchjest uruchamiany jako root, ale <(rurociągów z pliku) nie jest.

Jayen
źródło
1
Po prawej: praktyczny punkt widzenia często zawiera wskazówki, które są trudniejsze do zauważenia tylko na stronach podręcznika użytkownika. Aby przezwyciężyć podobną sytuację, musisz więcej ćwiczyć na siłowni [:-)] np. Napisać coś w stylu sudo /bin/bash -c "./patch -p0 < /root/patch". Jeszcze bardziej delikatny jest przypadek, w którym przekierowanie służy do utworzenia pliku >. W pierwszej kolejności utworzysz plik, który należy do użytkownika tylko wtedy, gdy masz wystarczające prawo do zapisu w końcowym katalogu. W ten drugi sposób utworzysz plik należący do roota ... ciemna strona Uniksa ;-)
Hastur
1

Wierzę, że podczas korzystania z dostępu sudo tworzony jest plik dziennika, jednak przy bezpośrednim dostępie przez root nie ma.

Ashley Redman BSc
źródło
0

To zależy od tego, jak drobnoziarnisty ma być dostęp do katalogu głównego. Jeśli masz kilku użytkowników wykonujących różne zadania w systemie, sudo byłoby bardziej idealne. Jednym z przykładów, z których często korzystam, jest konieczność ponownego uruchomienia aplikacji lub bazy danych. Bezpieczeństwo zawsze najlepiej jest robić najmniej uprzywilejowane. Używam grup i zezwalam tym grupom na wykonywanie wyraźnych działań. Dobra książka opisująca ten proces to „Sudo Mastery: Kontrola dostępu użytkownika dla prawdziwych ludzi”. Właściwie jest to dobra książka o sudo w ogóle ...

meredithkm
źródło