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

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.

• 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.

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