mc: витруальные консоли под не-root

$ mc --help|grep shell
  -U, --subshell            Включить поддержку
  -u, --nosubshell          Отключить поддержку

-U поведение не изменяет, по нажатию любой кнопки панели возвращаются.

> suid на /usr/lib/mc/cons.saver 

Может сразу SUID на bash/rm/cp/mv поставить?

У вас явно бардак с правами на файлы в /dev.

На /dev/pts права выставляться должны автоматом правильно. Примерно так:

[birdie@localhost pts]$ ls -l /dev/pts
total 0
crw--w---- 1 birdie tty 136, 0 2007-11-20 17:30 0
crw------- 1 birdie tty 136, 1 2007-11-22 18:10 1
crw------- 1 birdie tty 136, 2 2007-11-22 18:10 2
crw------- 1 birdie tty 136, 3 2007-11-22 10:44 3
crw------- 1 birdie tty 136, 4 2007-11-22 18:10 4
crw--w---- 1 root   tty 136, 5 2007-11-22 14:29 5
crw------- 1 birdie tty 136, 6 2007-11-22 18:11 6
crw------- 1 birdie tty 136, 7 2007-11-22 14:33 7
crw--w---- 1 birdie tty 136, 8 2007-11-22 14:33 8
crw--w---- 1 birdie tty 136, 9 2007-11-22 18:11 9

[birdie@localhost ~]$ ls -l /dev/console
crw------- 1 birdie root 5, 1 2007-11-21 12:51 /dev/console

Вы явно что-то извратили с PAM или /etc/security/console.perms

$ export TERM=linux
$ mc

?

>> suid на /usr/lib/mc/cons.saver
>Может сразу SUID на bash/rm/cp/mv поставить?
Глаголить suid зло все горазды, предложите лучше вариант как настроить правильно права в /dev, чтобы его снять.

>У вас явно бардак с правами на файлы в /dev.
Права на /dev у нас задаются в /etc/udev/permissions и там ничего не менялось

>На /dev/pts права выставляться должны автоматом правильно. Примерно так:
Как я уже сказал выше, режим монтирования 620, поэтому у созданных файлов права такие же, как у вас: rw--w----

Проблема в том, чтоб под обычным пользователем, mc не может создать там эти файлы.

>crw------- 1 birdie root 5, 1 2007-11-21 12:51 /dev/console
Тут права совпадают тоже

>Вы явно что-то извратили с PAM или /etc/security/console.perms
Тут ничего не менялось

>$ export TERM=linux
>$ mc
TERM такой же, пробовал TERM=xterm - не помагает.

Кстати да, забыл сказать - всё это под консолью, без иксов, если имеет значение.

добавь в рулесы udev:

KERNEL=="vcs", GROUP="tty"
KERNEL=="vcs[0-9]*", GROUP="tty"
KERNEL=="vcsa", GROUP="tty"
KERNEL=="vcsa[0-9]*", GROUP="tty"


ну и сунь юзера в группу tty

>добавь в рулесы udev:
>
>KERNEL=="vcs", GROUP="tty"
>KERNEL=="vcs[0-9]*", GROUP="tty"
>KERNEL=="vcsa", GROUP="tty"
>KERNEL=="vcsa[0-9]*", GROUP="tty"
>
>
>ну и сунь юзера в группу tty

Спасибо, это помогло снять suid с cons.saver, но проблема с виртуальным терминалом ещё осталась.

ну что ещё, остаётся strace mc :)

А почему такой геморрой в Debian? (Просто интересно).

> А почему такой геморрой в Debian? (Просто интересно).

нет в дебиане никакого геммороя. походу лично у топистартера что-то слетело.

+1

Поставь Debian Etch или Ubuntu, и не имей окружающих в моск, ибо unstable для обычного юзера не предназначен.

Всем спасибо за душевные отзывы в адрес линейности моих конечностей...

>ну что ещё, остаётся strace mc :)
Именно этим сейчас планирую заняться

>нет в дебиане никакого геммороя. походу лично у топистартера что-то слетело.
>Поставь Debian Etch или Ubuntu, и не имей окружающих в моск, ибо unstable для обычного юзера не предназначен.

В действительности у меня эта проблема с Debian EABI, спецальная сборка под ARM (на Zaurus'е крутится), так что откатиться до stable не получится.

> ибо unstable для обычного юзера не предназначен.

злостное 4.2. юзаю анстейбл. вышеописанных проблем нет.

Я в шоке, господа!

Осstraceил под rootом и обычным пользователем, наблюдаю отличия. В первом случае всё как положено, обращается к ptmx, создаётся pts/0. Во втором - вообще нет обращений к ptmx. Ага, т.е. дело тут вовсе не с правами, начал смотреть в других направлениях. Покапался, потыкался, вообщем оказалась причина мне совершенно непонятная: MC так странно себя ведёт из-за того, что под обычным пользователем у меня в качестве командного интерпретатора в /etc/passwd прописан /bin/sh, а под rootом - /bin/bash. При этом /bin/sh - это симлинк на /bin/bash.

Кто-нибудь может объяснить это? По мне так никакой разницы быть не должно, запускается же один и тотже bash.

# bash --version:
GNU bash, version 3.1.17(1)-release

попробуй ради эксперимента, создать тестового пользователя с шеллом zsh и в нем проверить.

ОК, вечером попробую, а цель эксперимента какая?

цель - восприимчивость mc к дефолтному шеллу.

я бы даже сказал, проверить реакцию mc на sh. есть такое смутное подозрение, что он может на него неадекватно реагировать...

Попробовал с zsh. Результаты такие:
1. в /etc/passwd указан /bin/zsh. /bin/zsh - ссылка на /bin/zsh4.
Вартуальный терминал в mc работает
2. поправил /bin/sh, чтобы указывать на тот же /bin/zsh4. В /etc/passwd указал /bin/sh.
Вартуальный терминал в mc перестал работать.

Так что проблема именно в /bin/sh.

> Так что проблема именно в /bin/sh.

я бы даже сказал, в неоднозначной реакции mc на /bin/sh :)