xauth не подчищает за собой

Покажи свой /etc/pam.d/su?

А это вообще не имеет отношения к xauth и никаких файлов не создает.

su и не создает! Создает pam_xauth.so. И вот это закомментируй, который зачем-то через PAM вызывает pam_xauth.so. Можешь весь показать? Как он дошел до этого места?

/etc/pam.d/su:session optional pam_xauth.so

Проще будет, если закомментируешь строчку в pam.d/su и тупо проверишь, будет создаваться или нет.

Убрал все закомментированные участки. Закомментироваными идут они в дистрибутиве, я вообще там ничего не трогал. Ни в одном файле там pam_xauth.so не используется.

auth       sufficient pam_rootok.so

session       required   pam_env.so readenv=1
session       required   pam_env.so readenv=1 envfile=/etc/default/locale

another user
session    optional   pam_mail.so nopen

@include common-auth
@include common-account
@include common-session

В Gentoo, Debian и Fedora эти pam.d несколько по-разному устроены. Я уже заметил, когда помогал другим. Вот, например, в Fedora (или centos): su не распознаёт пароль root для не root-пользователя (комментарий)

А su какие права имеет? ls -l /bin/su

А su какие права имеет? ls -l /bin/su

Это важный, кажется, вопрос для понимания процессов. Я, кажется, понял, откуда файлы в /root берутся.

-rws--x--x

-rws--x--x

Вроде ок. Без suid бита не работает pam_xauth.so (в ман написано). А раз работает, то я бы его комментировал вообще. Иначе он все время при su пытается форвардить куки к руту.

man pam_xauth

Стиарает он эти куки, когда сессия su завершается корректно. Если ты из su в перезагруз уходишь, то файлы /root/.xauthXXXXXX остаются висеть навсегда.

pam_xauth работает только если программа имеет suid бит. У тебя он есть, об этом написано в документации.

Со вчерашнего дня перестали пускаться графические приложения приложения из-под su из pts из терминатора из иксов по причине перемещения графической сессии из vt07 в vt11, комментирование строки с pam_xauth исправило положение.

Со вчерашнего дня перестали пускаться графические приложения приложения из-под su из pts из терминатора из иксов по причине перемещения графической сессии из vt07 в vt11

Что-то не могу пока понять, как в этом мог быть виноват pam_xauth.

комментирование строки с pam_xauth исправило положение.

Насколько я понимаю, в случае отсутствия pam_xauth.so в правилах, пользователь root для установления соединения с X-сервером использует cookie пользователя прямо из его домашней директории. Переменная XAUTHORITY просто копируется.

man su:

Если параметр --login указан, то переменные окружения $TERM, $COLORTERM, 
$DISPLAY и $XAUTHORITY копируются (если они установлены).

С root как раз проблем и не будет без pam_xauth.so, так как он и так имеет доступ ко всем каталогам. А вот если надо было бы пользователю «A» запустить у себя графическую программу, как будто бы ее запускает пользователь «B», а у них нет доступа к каталогам друг друга, то вот тогда надо, чтобы кто-то более весомый отфорвардил cookie от «A» к «B», чтобы приложению можно было подсоединиться к открытому дисплею. Вот это и делает pam_xauth.so. Плохо лишь то, что он срет в домашней директории этими вот .xauthXXXXXX, которые при внезапной перезагрузке посреди сессии su, остаются. Можно, конечно, их автоматом как-то чистить.

Что-то не могу пока понять, как в этом мог быть виноват pam_xauth.

Он не виноват, просто я поленился донастроить.

Насколько я понимаю, в случае отсутствия pam_xauth.so в правилах, пользователь root для установления соединения с X-сервером использует cookie пользователя прямо из его домашней директории. Переменная XAUTHORITY просто копируется.

Так и есть.

Можно, конечно, их автоматом как-то чистить.

Ещё один костыль городить? У меня однопользовательская машина, мне это не нужно, но на всякий случай буду иметь в виду. Благодарю.

Ещё один костыль городить? У меня однопользовательская машина, мне это не нужно, но на всякий случай буду иметь в виду. Благодарю.

Это только на тот случай, если этот pam_xauth.so вообще нужен. Если нужен, то от создания этих файлов не уйти. Вот в Debian этот модуль не используется ни в su, ни в sudo.

Мне это не понадобится по двум причинам: 1) я везде рут (то есть на всех машинах имею права суперпользователя). 2) на всех машинах не более одного пользователя, почти ни у кого нет прав на запуск su и sudo (если, конечно, sudo в системе есть, но его обычно нет по соображениям безопасности).

от создания этих файлов не уйти

Перенастроить бы использование этих файлов в ~/.Xauthority, но я пока не нашёл, как это сделать.

Перенастроить бы использование этих файлов в ~/.Xauthority, но я пока не нашёл, как это сделать.

~/.Xauthority у root или у user? Какой вообще юзкейс у тебя?

У рута, конечно. У юзера как раз всё в порядке с этим.

Эксперименты сильно разные бывают, и система сильно изменяется обычно раз в два-три месяца. Но чаще всего я пускаю из pty от рута только geany, spacefm, gparted и emerge.

А интересует вариант с pam_xauth.so или без него? Мы ведь говорим о варианте без pam_xauth.so?

Если ты в root через su (без "-") оказываешься, то тебе и не надо ничего делать, все должно сразу работать, так как DISPLAY и XAUTHORITY копируются в его environment, а доступ у root к XAUTHORITY пользователя есть.

А если ты оказываешься root через login, через ssh или 'su -', то тогда этих переменных нет и их надо установить. Можно в /root/.profile экспортировать DISPLAY и XAUTHORITY. Лучше при этом выдать текстовое сообщение, чтобы потом не удивляться, что происходит, когда уже давно забыл, что это добавил. Например:

export DISPLAY=:0
export XAUTHORITY=/var/run/slim.auth

Должно работать, но это фиксированный случай, когда у тебя всегда только DISPLAY=:0. А в общем случае можно извлекать при старте сессии root связки дисплей-ключ из xauth, в котором есть опции [n]extract, [n]merge, list, add.

На моей домашней машине мне хватит и наследования $XAUTHORITY и $DISPLAY от пользователя владельца графической сессии. А на остальных машинах мне манипулирование графической сессией (в т.ч. запуск графических утилит) не нужно вообще, там мне пользовательских данных касаться вообще не нужно.

export XAUTHORITY=/var/run/slim.auth

Негоже. Лучше уж export XAUTHORITY=$HOME/.Xauthority. Хотя бы потому, что графическая сессия, в которую попадает root может быть запущена не из slim, а, например, из startx или ещё какими неведомыми путями (которые все не учесть).

А если ты оказываешься root через login, через ssh или 'su -', то тогда этих переменных нет и их надо установить.

надо установить

Зачем? По ssh xauth нам не нужен, через login в tty я могу дёрнуть графическое приложнение и без этого, но рулить ими я в обоих случаях не смогу.

Негоже. Лучше уж export XAUTHORITY=$HOME/.Xauthority. Хотя бы потому, что графическая сессия, в которую попадает root может быть запущена не из slim, а, например, из startx или ещё какими неведомыми путями (которые все не учесть).

Этого я не знал.

Зачем? По ssh xauth нам не нужен, через login в tty я могу дёрнуть графическое приложнение и без этого, но рулить ими я в обоих случаях не смогу.

Я же не знаю юзкейса, поэтому и спрашивал. Может, тебе надо из сессии root запустить что-то пользователю от его имени принудительно. Скажем, # su -l user -c geany. Но раз нет, то и уже и не важно.

через login в tty я могу дёрнуть графическое приложнение и без этого

Без xauthority (файл или переменная) не дернется — ругнется (должен), что к дисплею не может подключиться. Я вот прямо сейчас логинюсь как root через login в tty у себя, а переменной XAUTHORITY нет, файла ~/.Xauthority тоже нет. На запуск приложения от root из консоли на дисплей пользователя идет закономерная ругань: cannot open display :0. Как только XAUTHORITY указываю на свой /home/zubok/.Xauthority, то все пляшет (и должно). Но раз это тоже не юзкейс, то и пофиг уже.

о рулить ими я в обоих случаях не смогу.

Это понятно. Но вот если mplayer запустишь, то сможешь. :)

На домашней машине я могу плясать как хочу, это понятно, а вот на остальных мне нужно только апдейты ставить, да систему в стабильное состояние приводить, отслеживая логи, правя конфиги и перезапуская демоны. В первом случае я могу делать что хочу и как хочу, ведь это мой собственный комп. А вот во втором случае пользователю не обязательно знать о моём присутствии — пусть продолжает выполнять свою работу, пока я выполняю свою, если мы не будем друг другу мешать. Если пользоваель мне как-то мешает, я найду способ отследить положение его графической сессии, и отправить ему графическое же предупреждение, а уж перехватить его $XAUTHORITY и подавно. От рута я могу сделать всё, что нужно, ведь их машины обслуживаю я, и я должен знать, что и где у них находится.

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

Да, без $XAUTHORITY нельзя запустить графическое приложение от другого пользователя, который является владельцем графической сессии, но это и не нужно, если я работаю удалённо. А когда я физически нахожусь у компа-пациента, то мне эти пляски с бубном и не понадобятся — я могу начать графическую сессию от рута или залогиниться рутом в pty в графической сессии текущего пользователя, если в этом есть реальная необходимость. Плюсы графической сессии в малом — быстрее разметить диски и выставить партишнам нужные флаги из gparted, чем городить последовательность команд в терминале (при установке дистра, например), править конфиги пачками в geany, вместо того, чтобы занимать все доступные tty. А вот файловый менеджер от рута я использую только у себя на домашней машине, на работе я себе этого позволить не могу и не хочу.

Любопытное. Я добавил session optional pam_xauth.so в /etc/pam.d в самый конец файла. Решил поглядеть на то, при каких условиях у /root остаются cookie. Сделал для проверки три сессии:

# Просто сессия без ничего
$ su
# Запустил aumix
$ su -c aumix
# Запустил графический Emacs
$ su -l root -c emacs

В процессах висит, соответсвенно:

 3150 root      20   0  4364 1364 1080 S   0,0  0,1   0:00.00 su
 3179 root      20   0  4364 1364 1080 S   0,0  0,1   0:00.00 su
 3122 root      20   0  4364 1360 1080 S   0,0  0,1   0:00.00 su
 3154 root      20   0 21564 8348 7008 S   0,0  0,8   0:00.12 aumix
 3190 root      20   0 28100  13m 8736 S   0,0  1,4   0:00.78 emacs

В /root имеем

/root/.xauthOekPOS  /root/.xauthPbgDzE  /root/.xauthU2LTU5  

Теперь нагло делаем # reboot от root. Также делал и # halt

Перегружается комп и никаких /root/.xauth* нет. Они все уходят. По идее оно так и должно быть, потому что reboot вызывает shutdown, а shutdown перед тем, как выключить компьютер посылает приложениям SIGTERM и они корректно завершаются. То есть su должен корректно закрыть сессию, а закрытие сессии su должно удалить временную cookie. То есть проблема у меня не возникает при корректном выходе посреди открытых сессий.

Но! При выключении компьютера кнопкой Power (принудительное, аварийное), cookie, разумеется, остаются.

Я это все для справки. Для тех, кто наткнется на эту тему когда-то. Скорее всего, причина скопления .xauth* кроется в некорректном выключении компьютера.

Это, конечно, всё так и должно быть, но у меня это почему-то не так. Почему — неизвестно. Выяснить это мне пока не удалось. Должен ли кто-то конкретный подчищать за xauth? Может ли завершение сессии произойти раньше зачистки? То есть не при нажатии кнопки, а при корректном завершении.

То есть не при нажатии кнопки, а при корректном завершении.

А вот я и спрашивал как-то выше, как завершаете сессию? Чем? Может быть, проверю.

Должен ли кто-то конкретный подчищать за xauth?

Полагаю, что нет. Если только свое что-то писать. Сам pam_xauth.so этого не делает. Он только создает новые и неповторяющиеся и обязательно удаляет, если сессия su заканчивается (pam_xauth cannot be told to not remove the keys when the session is closed). Я все-таки считаю, что этот сервис PAM нужен в очень хитрых ситуациях. Для запуска приложений от root он точно не нужен.

Я так и не понял суть моей проблемы. Просто закомментировал ненужное в нужном файле. Всё работает, с xauth я устал бороться.

Я так и не понял суть моей проблемы.

Если pam_xauth.so есть, то корень, скорее всего, в том, как осуществляется выключение компьютера. Наверняка приходилось сто раз выходить, когда сессии su открыты. Вопрос только в том, как именно выход устроен. Ну и аварийный выход гарантировано оставляет cookie.

Просто закомментировал ненужное в нужном файле. Всё работает, с xauth я устал бороться.

И правильно. Есть еще один уровень управления доступом: если создать пустые файлы ~/.xauth/export и ~/.xauth/import, то cookie у root не создаются, но при этом pam_xauth.so берет на себя управление переменной XAUTHORITY. Если pam_xauth.so форвардит .xauthXXXXXX, то устанавливает XAUTHORITY=/root/.xauthXXXXXX. Если же из-за пустого export стоит запрет на создание (даже у root), то он просто unset делает и переменной XAUTHORITY вообще нет, даже копированной от пользователя. Затирает ее, и все.

Благодарю за информацию. Возможно, она пригодится в будущем.