Чому я отримую "екран закінчується" без кореня?

Я встановив екран на Fedora 19. Коли я тестую команду як root віддалено через SSH, вона працює чудово. Наприклад, якщо я ввожу screenновий емулятор термінала, запускається і чекає команд. Я можу від'єднати його і т. Д. Однак, коли я намагаюся зробити те саме, коли я віддалено ввійшов через SSH як стандартний користувач, команда негайно припиняється. Єдине повідомлення, яке я бачу, - це [screen is terminating].

Хтось уже мав цю проблему? Це пов’язано з поганими дозволами?

Оновлення:

$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/var/run/utmp", O_RDONLY)         = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/var/run/screen", {st_mode=S_IFDIR|0775, st_size=60, ...}) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++

Я намагався змінити дозволи на 777, але потім, коли я виконую screen, я отримую:

Каталог '/ var / run / screen' повинен мати режим 775.

Тому я змінив свої зміни.

Поворот між "повинен мати режим 777" і "повинен мати режим 775" викликаний strace.

screenЗазвичай це налаштована або встановлена ​​жорстка програма. Під час його виконання він отримує додаткові привілеї, які використовуються для створення файлів сокет та / або модифікації utmp.

Коли процес відстежується, налаштування та setgid відключаються. Процес відстеження, контрольований менш привілейованим користувачем, може перейняти відстежений процес, тому він повинен запускатися без додаткових привілеїв, щоб уникнути надання оригінальному користувачеві занадто великої потужності.

screen виявляє, запускається він із встановленими привілеями, встановленими жорсткими привілеями чи ні, і відповідно коригує його очікування дозволів каталогу.

Таким чином, це створює клас проблем, з якими неможливо легко налагодити strace.

Але якщо ви корінь, є рішення! Якщо процес відстеження працює як root, то відстежений процес може нормально отримувати привілеї. Отже, ось що ви робите:

1. Відкрийте 2 нових термінали
2. У першому терміналі увійдіть до віддаленої машини як root
3. На другому терміналі увійдіть до віддаленої машини як звичайний користувач
4. Використовуйте psдля отримання PID процесу оболонки звичайного користувача у другому терміналі
5. У першому терміналі запустіть strace -f -p SHELLPID
6. На другому терміналі запустіть екран і слідкуйте за тим, як він не виходить
7. У першому терміналі тепер у вас є журнал напружень, який вам потрібен, щоб з’ясувати, що насправді не так.

Ключовим доповненням до straceкоманди є -fопція, яка вказує їй простежити дочірні процеси. Вам потрібно, щоб простежити на екрані, який буде дочірньою частиною оболонки, яку ви вказали -p.

Мені також подобається використовувати -ffі вказати вихідний файл з -o, як у

strace -ff -o /tmp/screentrace -p SHELLPID

який створить окремий вихідний файл для кожного дочірнього процесу. Потім ви читаєте їх, less /tmp/screentrace*і результат зазвичай є більш чистим, ніж те, що ви отримуєте за допомогою синглу -f.

ОНОВЛЕННЯ

Тепер, коли я побачив висновок страйку, я не знаю, що саме пішло не так, але ця лінія є найдивнішою справою:

chown("/dev/pts/2", 1002, 5)            = -1 EPERM (Operation not permitted)

Кілька рядків раніше, це створило pty, який було виявлено TIOCGPTNцифрою 2.

open("/dev/ptmx", O_RDWR)               = 5
...
ioctl(5, TIOCGPTN, [2])                 = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0

Але придушити це не вдалося. Я не знаю, чому цей чуун провалився б, але невдача хоуну справді дає правдоподібну причину, чому екран здався. Ви можете отримати трохи більше інформації, додавши -vдо опцій страйку і переглянувши statпісля цього, TIOCGPTNщоб побачити, кому належить /dev/pts/запис.

З можливих причин цієї помилки - неправильна політика selinux, але згідно з Redhat bugtracker такі помилки були виправлені у fedora 17/18.

Як вирішення, ви можете змінити змінну SCREENDIRв собі ~/.bashrcна щось подібне $HOME/.screen.

Коли я зіткнувся з цим повідомленням про помилку Мені довелося скорегувати свої дозволи на таке:

chmod 2775 /usr/bin/screen

І це вирішило для мене питання. 2 дуже важливі для правильних дозволів доступу.

Слід прочитати більше про SUID, SGID, Sticky Bit, ACL та те, як вони впливають на доступ.

Екранна команда вже виконувалася. Тому я припинив його і повторно ввів команду. Так, це не дуже хороша роздільна здатність, як інші, але для цього потрібно менше часу.

Просто знайдіть ps, знайдіть PID, вкажіть PID і знову продовжуйте команду перезапису екрана.

Якщо ви виконуєте кілька команд на екрані, переконайтеся, що ви припинили правильний процес, пов'язаний зі своїм терміналом.

Я знайшов цю проблему вирішеною після коментарів до наступного рядка в / etc / fstab та перезавантаження:

devpts         /dev/pts        devpts  defaults        0       0

Переконайтесь, що ніхто screenне використовує цей пристрій

Цього можна досягти за допомогою /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

А потім вбийте цей процес, якщо це так.

Чомусь за цієї умови sudo screenвсе ж можна отримати доступ до пристрою, але тоді це з'єднання пропустить символи, які споживає інший screen.

Переконайтеся, що користувач прочитав та дозволив записати файл

Наприклад, на Ubuntu ви хочете додати користувача до dialoutгрупи: /ubuntu//a/133244/52975

Я отримав точно таку ж проблему і досить схожий страйк-вихід.

Це виправлено:

sudo chmod u+s /usr/bin/screen
sudo chmod 755 /var/run/screen

кредити: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminate-immediate-4175444530/