su: Odmowa dostępu pomimo poprawnego hasła

W mojej nowej instalacji Gentoo su nie działa jako użytkownik inny niż root: po wprowadzeniu prawidłowego hasła pojawia się komunikat „su: Odmowa dostępu”. Co może być tego przyczyną? Próbowałem już ponownie zainstalować pakiet zawierający /bin/su.

EDYCJA: sudo działa.

Musisz dodać użytkownika do wheelgrupy :

 gpasswd -a youruser wheel

Alternatywnie, można wyłączyć sprawdzanie członkostwa grup dla suw pamedytując

 /etc/pam.d/su

i komentując ten wiersz:

auth       required     pam_wheel.so use_uid

Wymaga, aby użytkownicy byli w wheelgrupie, aby móc zmienić użytkownika. Przełączanie użytkowników jako użytkownik inny niż root działa ponownie, gdy pammoduł ten jest wyłączony dla su.

Może być wiele problemów. Sprawdź niektóre z tych elementów, używając hipotetycznego użytkownika, erik:

1. Czy erik jest członkiem grupy kół ( groups)?
2. Czy podajesz hasło roota? (I nie hasło do erika)
3. Czy /bin/suma te uprawnienia: rwsr-xr-x(Czy to jest setuid root? ls -l /bin/su)
4. Czy możesz zalogować się jako root za pomocą konsoli?
5. Czy przejrzałeś dzienniki w poszukiwaniu wskazówki w komunikacie o błędzie?
6. Czy włączyłeś grsecurity w jądrze?
7. Czy to kiedykolwiek działało? Jeśli tak, kiedy to się zepsuło?
8. Co się stanie, jeśli erik zrobi sudo su -?

Może być wiele przyczyn . Jest bardzo prawdopodobne, że przyczyna pojawia się w logach systemowych. Poszukaj/var/log plików, które zostały zmodyfikowane podczas supróby (nazwa pliku zależy od konfiguracji syslog). Jeśli masz problemy z interpretacją wpisów w dzienniku, skopiuj je i wklej do pytania.

Skompilowałem cień w trakcie budowania Linuksa ze Scratch 8.4 i mogłem zalogować się jako root lub nieuprzywilejowany użytkownik, ale nie mogłem su z nieuprzywilejowanego użytkownika na root, jak w przypadku Erika powyżej. Okazało się, że plik binarny su był własnością mojego nieuprzywilejowanego użytkownika. Działa po tym, jak zmieniłem plik binarny su na root i zrobiłem „chmod u + s” na pliku binarnym su.