„Nie można ustawić terminala grupy procesów” podczas su innemu użytkownikowi jako powłoce logowania


16

Uwaga: przeczytaj zaktualizowane informacje zaczynające się od „EDYTUJ” w pobliżu połowy tego postu - środowisko i tło tego problemu uległy zmianie

Mam tutaj standardową instalację Debiana 6.0, którą postanowiłem przenieść do repozytoriów testujących Debiana. Zrobiłem to, wymieniając odniesienia do repozytoriów Squeeze w mojej pliku sources.list, aby zamiast tego korzystać z repozytoriów Testowanie.

Po zainstalowaniu pakietu i ponownym uruchomieniu komputera pojawia się następujący błąd podczas próby su - innemu użytkownikowi:

root@skaia:~# su joebloggs -
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Jeśli pominę -, to nie nastąpi.

Zauważ, że użytkownicy mogą zostać rootem poprawnie, wydaje się, że dzieje się to tylko podczas przełączania z roota na kogoś innego i używania - w celu uzyskania środowiska tego użytkownika.

Google jest tu w większości bezużyteczny. Jedyne, co mogę znaleźć, to odniesienia z 2011 roku dotyczące suxpakietu, które wydają się być naprawione w międzyczasie.

Wygląda i pachnie bardzo podobnie do błędu aktualizacji, który można naprawić, poprawiając odpowiedni pakiet we właściwy sposób. Po prostu nie mam pojęcia, od czego zacząć - poza tym mój system działa całkowicie normalnie i zgodnie z oczekiwaniami.

EDYTOWAĆ

To się teraz dzieje na stabilnej maszynie Debiana , jak opisano powyżej. Tym razem nie ma aktualizacji ani nic, po prostu stabilny.

Tak, rok później. Nadal nie mam pojęcia, na czym polega problem.

Oto jak teraz wygląda (niewiele się zmieniło):

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
terraria@skaianet:~$ tty
/dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/0
crw--w---- 1 root root 136, 0 Oct 10 19:21 /dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/
crw--w---- 1 root root 136, 0 Oct 10 19:21 0
crw--w---- 1 root root 136, 2 Sep 22 17:47 2
crw--w---- 1 root root 136, 3 Sep 26 19:30 3
c--------- 1 root root   5, 2 Sep  7 10:50 ptmx

Wygenerowano tak:

root@skaianet:~$ strace -f -o tracelog su terraria -

.. również pojawia się pewne mylące zachowanie. Te wiadomości są dość mylące. Niektóre wybrane linie:

readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
#Error code 10? 
15503 open("/dev/tty", O_RDWR|O_NONBLOCK) = -1 ENXIO (No such device or address)
#Yes there is, and I can interact with it normally
15503 ioctl(255, TIOCGPGRP, [32561])    = -1 ENOTTY (Inappropriate ioctl for device)

Połączyłem pełny wynik tej sesji strace - wszystko, co zrobiłem, to uruchomiłem polecenie su, a następnie natychmiast ctrl + d z terminalu.


1
Cześć Mike. Znalazłeś problem?
Mircea Vutcovici

Odpowiedzi:


33
  • su - usernamejest interpretowany przez użytkownika sujako „uruchamianie powłoki nazwy użytkownika jako interaktywnej powłoki logowania”
  • su username -jest interpretowany przez użytkownika sujako „uruchom następujące nieinteraktywne polecenie ( -) jako nazwę użytkownika
  • ten ostatni działał w ogóle tylko dlatego, że:
    • Twoje suprzechodzi końcowe argumenty shdo parsowania
    • shodbywa -się na myśli „Uruchom jako powłoki logowania (czytaj /etc/profile...)”

Ale tak naprawdę interesuje Cię: dlaczego nieinteraktywny ? Udostępnianie terminalu sterującego między uprzywilejowanym rodzicem a nieuprzywilejowanym dzieckiem pozostawia cię podatnym na „ eskalację uprawnień TTY pushback ”, czyli TIOCSTIbłąd, więc chyba, że ​​naprawdę go potrzebujesz, to się su od niego odłączy . Kiedy używałeś su username -formularza, su wywnioskowałeś, że nie potrzebujesz terminalu sterującego .

Tylko procesy z terminalem sterującym mogą mieć liderów sesji, które manipulują grupami procesów (wykonują kontrolę zadań); ślad, który podałeś, bashwykrywa, że ​​nie może to być lider sesji.

Wspominasz:

Dziwniejsze staje się to, że obie formy działają dobrze na Ubuntu i CentOS 6, jednak na waniliowym Debianie tylko pierwsza forma działa bezbłędnie.

Warianty ignorując jak suxi sudoistnieją co najmniej trzy [1] wersje suna Linuksa: coreutils, util-linuxi shadow-utilsod którego pochodzi Debian. Ta ostatnia strona wskazuje:

Ta wersja su ma wiele opcji kompilacji, z których tylko niektóre mogą być używane w poszczególnych witrynach.

a Debian pochodzi z flagą old_debian_behavior; inne wersje mogą mieć podobne opcje czasu kompilacji / środowiska wykonawczego. Innym powodem zmienności może być dyskusja [2] na temat tego, czy sunależy kiedykolwiek użyć upuszczenia uprawnień w ten sposób i czy TIOCSTIbłąd jest w ogóle błędem (Redhat pierwotnie zamknął go „WONTFIX” ).

[1]: Edycja: dodaj SimplePAMAppsi hardened-shadowdo tego.

[2]: Solar Designer ma tam kilka (starych) opinii, które moim zdaniem są warte przeczytania.


2
To doskonała odpowiedź, a co najważniejsze, dokładnie wyjaśnia, dlaczego. Chciałbym, żebyś tu był rok temu :)
Mikey TK

1

Sprawdziłbym własność i uprawnienia na / dev / pts * lub nową konfigurację udev związaną z urządzeniami / dev / pts, która nie została zastąpiona podczas procesu aktualizacji.

Możesz także spróbować dowiedzieć się, co syscal generuje błąd, uruchamiając jako root:

strace -f su - username 2>stderr.log

2
Lepiej dodaj -ftę ścieżkę, na wypadek, gdyby su zdecydowała się uruchomić powłokę jako podproces, co wydaje się teraz powszechne. Syscall do ustawiania grupy procesów na pierwszym planie terminala jest ioctl(..., TIOCSPGRP, ...)i wiemy już, że nie powiódł się z ENOTTY (nieodpowiedni ioctl dla urządzenia), więc część śledzenia niewiele pomoże. -Można jednak porównać ciąg obu wersji polecenia ( zi bez ), aby dowiedzieć się, dlaczego TIOCSPGRP zawodzi.
Alan Curry

To wygląda na obiecującą szansę. W moim folderze / dev / pts są dokładnie dwa elementy, a mianowicie 0, uprawnienia ustawione na 600 posiadane przez użytkownika zalogowanego jako ptmxroot i posiadające uprawnienia zerowe.
Mikey TK,

1
Gdy pojawi się monit powłoki po No job controlwiadomości, uruchom polecenie, ttya powie ci, na którym tty jesteś. Więc ls -lto.
Alan Curry

@AlanCurry, masz rację, dodam -f. Dziękuję Ci!
Mircea Vutcovici

@AlanCurry - wrócił. Zaktualizowałem oryginalne pytanie o informacje sugerowane przez Mircea.
Mikey TK,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.