Вопросы Теги

'$XAUTHORITY' не появляется от 'нигде' на su+tmux

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

4
18.11.2018, 19:36
3 ответа

Вот то, что я думаю, происходит.

Когда Вы используете su и bash, su- сессия наследовала среду за исключением USER, HOME и SHELL, таким образом XAUTHORITY неподвижные точки к ~username/.Xauthority и все прекрасно. Однако (из страницы справочника), когда tmux сервер запущен:

... tmux копирует среду в глобальную среду; кроме того, каждая сессия имеет среду сессии. Когда окно создается, сессия и глобальные среды объединяются со средой сессии, переопределяющей любую переменную, существующую в обоих.

и я подозреваю (не зная детали вызова) это, когда Вы переключаете учетные данные, su попытки найти .Xauthority в /root и так как это не может найти тот, когда необходимо работать X приложение, это создает то. Я могу думать о паре путями, можно попытаться зафиксировать это:

  1. Вызвать su при помощи su -. Это скопирует по evironment реального пользователя
  2. Добавить set-environment <name> <value> к Вашему tmux конфигурация.

К сожалению, я не могу протестировать это, так как я недавно переключился на i3 (который является потрясающим), и у меня нет запасной машины.

1
27.01.2020, 21:02
  • 1
    установки За исключением того, что я вызываю su su-. Также echo "$XAUTHORITY" шоу там нет ~. Я попробую set-enviroment. сеть inet.ip.fw.one_pass сети inet.ip.fw.one_pass –  Maciej Piechotka 21.09.2010, 00:47
  • 2
    На самом деле я имел в виду ~ поскольку стенография к (что я предположил) была Вашим корневым каталогом. Я отредактировал. –  gvkv 21.09.2010, 02:26
  • 3
    не, i3 является i3, потрясающий потрясающий =P. –  Kent Fredric 15.02.2011, 11:40

Это могло произойти из-за неправильно сконфигурированного pam_xauth модуля PAM. Это, как предполагается, копирует Ваши ключи к временному файлу, когда Вы работаете su. Поведение, которое Вы описываете, согласовывается с pam_xauth, создающим временный файл, но так или иначе не копирующим ключи (возможно, потому что у Вас есть a ~/.xauth/export или a /root/.xauth/import).

0
27.01.2020, 21:02
  • 1
    у меня нет ни одного из тех, но xauth, загружается на su сессии (т.е. это находится в/etc/pam.d/su). –  Maciej Piechotka 18.11.2010, 02:19
[117332]Это случилось со мной, но на этот раз с переменной $COLORTERM.

Если запустить tmux на терминальном эмуляторе, у которого, например, COLORTERM=терминус, а после этого запустить еще один сеанс tmux даже на другом терминальном клиенте, у которого обычно COLORTERM=gnome-terminal, то этот новый сеанс будет пересекаться и наследует COLORTERM=терминус.

Этих утверждений достаточно, чтобы сделать вывод, что, к сожалению, сессии tmux не изолированы друг от друга, даже если Вы используете разные терминальные эмуляторы.

  1. Ваша подоболочка su, вероятно, наследует $XAUTHORITY от другого сеанса tmux, а точнее, от самого первого созданного сеанса tmux.[117339].
0
27.01.2020, 21:02

Теги

Похожие вопросы