"Неможливо встановити групу процесових терміналів" під час su для іншого користувача як оболонку входу


16

Примітка. Прочитайте оновлену інформацію, починаючи з "EDIT" біля півдороги цієї публікації - оточення та передумови цієї проблеми змінилися

У мене тут встановлено болотний стандарт Debian 6.0, який я вирішив перейти на сховища Debian Testing. Я зробив це, замінивши посилання на Squeeze repos в моєму Source.list, щоб замість цього використати тестові репости.

Після встановлення пакета та перезавантаження я отримую таку помилку при спробі подати заявку іншому користувачеві:

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

Якщо я пропущу -, цього не відбувається.

Зауважте, що користувачі можуть коректно отримувати корінь, але це, здається, трапляється лише при переході від root на когось іншого та використанні - для отримання середовища цього користувача.

Google здебільшого марний. Єдине, що я можу знайти, - це посилання з 2011 року щодо suxпакету, які, здається, були зафіксовані в середній час.

Це виглядає і дуже нагадує помилку оновлення, яку можна виправити, налаштувавши правильний пакет правильним чином. Я просто не маю уявлення, з чого почати - окрім цього, моя система працює повністю нормально і як очікувалося.

EDIT

Зараз це відбувається зі мною на стабільній машині Debian, як описано вище. Цього разу жодного оновлення чи нічого, просто стабільно.

Так, через рік. Досі не маю уявлення, в чому біса проблема.

Ось як це виглядає зараз (мало що змінилося):

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

Створено такий штрих:

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

..до того ж виявляється якась заплутана поведінка. Ці повідомлення досить заплутані. Деякі обрані рядки:

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)

Я пов’язав повний вихід цього сеансу strace - все, що я зробив, запустив команду su, а потім негайно ctrl + d вийшов з терміналу.


1
Привіт Майку. Ви знайшли проблему?
Mircea Vutcovici

Відповіді:


33
  • su - usernameінтерпретується вашим suзначенням "запустити оболонку імені користувача як інтерактивну оболонку входу"
  • su username -інтерпретується вашим suзначенням "запустити таку неінтерактивну команду ( -) як ім'я користувача "
  • останні працювали взагалі лише тому, що:
    • suпередає ваші аргументи shдля аналізу синтаксису
    • shприймає -означає «біг в якості реєстраційної оболонки (читати /etc/profile...)»

Але те, що вас насправді цікавить, це: чому неінтерактивний ? Поділ керуючого терміналу між привілейованим батьком та непривілейованою дитиною залишає вас вразливим до " ескалації привілеїв TTY відкликання ", так само TIOCSTIпомилка, тому, якщо вам це справді не потрібно, він не su відривається від нього . Коли ви використовували su username -форму, su зробили висновок, що вам не потрібен контрольний термінал .

Лише процеси з керуючим терміналом можуть мати лідери сеансів, які маніпулюють групами процесів (виконують контроль за роботою); Даний вами слід bashвизначає, що він не може бути лідером сесії.

Ви згадуєте:

Дедалі дивнішим є те, що обидві форми відмінно працюють на Ubuntu та CentOS 6, проте на ванільній Debian лише перша форма працює без помилок.

Ігнорування варіанти подобається suxі sudoє принаймні три [1] версії suна Linux: coreutils, util-linuxі shadow-utilsз якого Debian приходить. Програма останнього вказує:

У цій версії su є багато варіантів компіляції, лише деякі з яких можуть використовуватися на будь-якому конкретному сайті.

і Дебіан приходить із прапором old_debian_behavior; інші версії можуть мати подібні параметри компіляції / часу виконання. Ще однією причиною мінливості може бути те, що була певна дискусія [2] щодо того, чи suслід коли-небудь використовувати для відмови від привілеїв таким чином і чи TIOCSTIпомилка є помилкою взагалі (Redhat спочатку закрив її "WONTFIX" ).

[1]: Редагувати: додати SimplePAMAppsі hardened-shadowдо цього.

[2]: Сонячний конструктор має там деякі (старі) думки, які, на мою думку, варто прочитати.


2
Це відмінна відповідь, і найкраще це саме пояснює, чому. Я б хотів, щоб ви були тут рік тому :)
Mikey TK

1

Я перевірив би право власності та дозволи на / dev / pts * або на нову конфігурацію для udev, пов’язаних з / dev / pts пристроями, які не були замінені в процесі оновлення.

Ви також можете спробувати з'ясувати, що syscal генерує помилку, запустивши як root:

strace -f su - username 2>stderr.log

2
Краще додайте -fцю стразу, на випадок, коли су вирішить запустити оболонку як підпроцес, що, здається, зараз є загальним. Системний виклик для встановлення групи процесу переднього плану терміналу є, ioctl(..., TIOCSPGRP, ...)і ми вже знаємо, що він не вдався з ENOTTY (Невідповідний ioctl для пристрою), тому частина страти не допоможе багато. Але деформацію обох версій команди (з і без -) можна порівняти, щоб з’ясувати, чому TIOCSPGRP не працює.
Алан Карі

Це виглядає як багатообіцяюча ведуча. Переглядаючи мою папку / dev / pts, є саме два елементи, а саме 0, дозволи, встановлені як 600, належать користувачеві, на якому я ввійшов, і ptmxroot, що має нульові дозволи.
Mikey TK

1
Коли ви отримаєте підказку оболонки після No job controlповідомлення, запустіть команду, ttyі вона підкаже, на якому титі ви працюєте. Тоді ls -lце.
Алан Карі

@AlanCurry, ти маєш рацію, додам -f. Дякую!
Mircea Vutcovici

@AlanCurry - повернувся. Я оновив оригінальне запитання з інформацією, яку запропонував Мірча.
Mikey TK
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.