Хотя ответ Юргена Вайгерта, по сути, охватывает это решение, мне сначала было не ясно, что там описывалось. Поэтому я добавлю свою точку зрения на случай, если кому-то еще понадобятся разъяснения.
Прежде всего, соответствующей документацией является X-страница безопасности .
Многочисленные источники в Интернете предлагают просто смонтировать сокет X11 unix и ~/.Xauthority
файл в контейнер. Эти решения часто работают на счастье, не понимая, почему, например, пользователь контейнера получает тот же UID, что и пользователь, поэтому нет необходимости в авторизации с помощью магического ключа.
Прежде всего, файл Xauthority имеет режим 0600, поэтому пользователь контейнера не сможет прочитать его, если у него не будет того же UID.
Даже если вы скопируете файл в контейнер и измените владельца, существует еще одна проблема. Если вы работаете xauth list
на хосте и контейнере с одним и тем же Xauthority
файлом, вы увидите разные записи в списке. Это потому, что xauth
фильтрует записи в зависимости от того, где он запущен.
X-клиент в контейнере (т.е. приложение с графическим интерфейсом) будет вести себя так же, как xauth
. Другими словами, он не видит магический файл cookie для сеанса X, запущенного на рабочем столе пользователя. Вместо этого он видит записи для всех «удаленных» сеансов X, которые вы открывали ранее (объяснено ниже).
Итак, вам нужно добавить новую запись с именем хоста контейнера и тем же шестнадцатеричным ключом, что и файл cookie хоста (т. Е. Сеанс X, запущенный на вашем рабочем столе), например:
containerhostname/unix:0 MIT-MAGIC-COOKIE-1 <shared hex key>
Уловка в том, что печенье должно быть добавлено xauth add
внутри контейнера:
touch ~/.Xauthority
xauth add containerhostname/unix:0 . <shared hex key>
В противном случае xauth
пометьте его так, чтобы оно было видно только вне контейнера.
Формат этой команды:
xauth add hostname/$DISPLAY protocol hexkey
Где .
представляет MIT-MAGIC-COOKIE-1
протокол.
Примечание. Нет необходимости копировать или связывать-монтировать .Xauthority
в контейнер. Просто создайте пустой файл, как показано, и добавьте cookie.
Ответ Юргена Вайгерта обходит это, используя FamilyWild
тип соединения, чтобы создать новый файл полномочий на хосте и скопировать его в контейнер. Обратите внимание, что сначала извлекается шестнадцатеричный ключ для текущего сеанса X из ~/.Xauthority
использования xauth nlist
.
Итак, основные шаги:
- Извлеките шестнадцатеричный ключ файла cookie для текущего сеанса X пользователя.
- Создайте новый файл Xauthority в контейнере с именем хоста контейнера и общим шестнадцатеричным ключом (или создайте cookie-файл с
FamilyWild
типом соединения).
Я признаю, что не очень хорошо понимаю, как FamilyWild
работает или как xauth
X-клиенты фильтруют записи из файла Xauthority в зависимости от того, где они запускаются. Дополнительная информация об этом приветствуется.
Если вы хотите распространять свое приложение Docker, вам понадобится стартовый скрипт для запуска контейнера, который получает шестнадцатеричный ключ для сеанса X пользователя и импортирует его в контейнер одним из двух способов, описанных ранее.
Это также помогает понять механизм авторизации:
- Клиент X (т.е. приложение с графическим интерфейсом), работающее в контейнере, ищет в файле Xauthority запись cookie, которая соответствует имени хоста контейнера и значению
$DISPLAY
.
- Если соответствующая запись найдена, X-клиент передает ее с запросом авторизации на X-сервер через соответствующий сокет в
/tmp/.X11-unix
каталоге, смонтированном в контейнере.
Примечание . Сокет Unix X11 по-прежнему необходимо монтировать в контейнере, иначе у контейнера не будет маршрута к X-серверу. Большинство дистрибутивов по умолчанию отключают доступ TCP к X-серверу.
Для получения дополнительной информации и лучшего понимания того, как работают отношения X клиент / сервер, полезно также рассмотреть пример пересылки SSH X:
- Сервер SSH, работающий на удаленной машине, эмулирует свой собственный X-сервер.
- Он устанавливает значение
$DISPLAY
в сеансе SSH для указания на свой собственный X-сервер.
- Он используется
xauth
для создания нового файла cookie для удаленного хоста и добавляет его в Xauthority
файлы как для локальных, так и для удаленных пользователей.
- Когда приложения с графическим интерфейсом запускаются, они общаются с эмулированным X-сервером SSH.
- Сервер SSH пересылает эти данные обратно клиенту SSH на локальном рабочем столе.
- Локальный SSH-клиент отправляет данные в сеанс X-сервера, запущенный на вашем рабочем столе, как если бы SSH-клиент был на самом деле X-клиентом (т. Е. Приложением с графическим интерфейсом).
- X-сервер использует полученные данные для визуализации графического интерфейса на вашем рабочем столе.
- В начале этого обмена удаленный X-клиент также отправляет запрос авторизации, используя только что созданный файл cookie. Локальный X-сервер сравнивает его с локальной копией.