Re: Запуск гуевых приложений в контейнере
03.06.2020 16:45, Victor Wagner wrote: $ xhost +inet:192.168.122.11 $ xhost +inet6:fd34:fe56:7891:2f3a::11 Ой, не рекомендую использовать xhost. В принципе, в сочетании с предыдущим советом достаточно просто ~/.Xauthority в контейнер скопировать. Потому что при этом значение DISPLAY внутри и снаружи будет совпадать, и магическое печенье подойдет. ... А вот не стоит делать так, чтобы не совпадали. Есть куча разных причин по которым лучше uid-ы синхронизировать, и это отнюдь не толко доступ к X-ам. Это еще по крайней мере кардинально упрощает обмен файлами с контейнером. Если UID'ы одинаковые, то по нынешним временам магические печенюшки уже не нужны. Гномовцы говорят, что когда-то кто-то подавился печенькой, и в gdm3 ее заныкали от пользователей от греха подальше. https://bugzilla.gnome.org/show_bug.cgi?id=651431 Теперь в x11-common складывают скрипт, который делает xhost +SI:localuser:<текущий_пользователь> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586685 А в ubuntu таких скриптов даже 2! https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1576454 Это по поводу совета давать untrusted доступ из контейнера к X-серверу в статье https://gudok.xyz/lxcdeb/
Re: Запуск гуевых приложений в контейнере
В Mon, 8 Jun 2020 09:20:54 +0700 Andrey Lu пишет: бо. А почему же я этого не нашел, где же это > > документировано... > >> https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ > > Мерси, подшил. > > вот ещё хорошая статья про применение контейнеров на десктопе > https://gudok.xyz/lxcdeb/ > Статья подробная, относительно современная. Мне понравилась. Не раскрыты, правда, темы "создание контейнера с другим дистрибутиовом" (хотя про это вскользь упоминается) и "создание контейнера с другой архитектурой с использованием qemu-user". Про вторую тему, правда я могу сказать "не делайте этого, если совсем не прижало". Потому что контейнер с архитектурой arm64 работающий на приличой рабочей станции amd64 по скорости сравним с Raspberry PI 3 и существенно уступает Nvidia Jetson Nano. Но иногда бывает, что позволить себе железную машинку с требуемой архитектурой нет возможности. Собирать-то еще можно кросс-компиляцией, хотя у сборки пакетов в режиме кросс-компиляции есть свои грабли, а тестировать как? --
Re: Запуск гуевых приложений в контейнере
06.06.2020 22:45, Dmitry Alexandrov пишет: > Maxim Nikulin wrote: >> 03.06.2020 14:29, Dmitry Alexandrov пишет: >>> Авторизация на Икс-сервере будет по UIDʼу, так что если не совпадают, то >>> надо явно разрешить, причем я не знаю, как это сделать не давая UIDʼу имя >>> на хосте, чтобы мочь приказать: >>> $ xhost +si:localuser:stanislav >>> >>> Кто знает, подскажите. >> Добавить "#" >> >> xhost +si:localuser:#$UID > О! Точняк, спасибо. А почему же я этого не нашел, где же это > документировано... > >> https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ > Мерси, подшил. вот ещё хорошая статья про применение контейнеров на десктопе https://gudok.xyz/lxcdeb/
Re: Запуск гуевых приложений в контейнере
В Sat, 6 Jun 2020 22:01:12 +0500 Stanislav Vlasov пишет: d> >>> Да, естественно, ибо с каких это пор Иксам стали требоваться > >>> всякие костыли типа ssh для отрисовки окон на другой машине? > > Тут вы пишете "на другой машине" > > >> Ключевые слова - авторизация и шифрование. > > > > Шифрование трафика виртуальной сети на локалхосте? А авторизация в > > Иксах есть, вы же сами про нее ниже пишете. > > А тут уже спрашиваете про локалхост. А вот! В наше время в пределах одного физического компьютера может существовать множество виртуальных. С точки зрения X-ов контейнер и хост - это разные машины. С точки зрения сетевой безопасности - одна и та же. (хотя на самом деле и тут могут быть нюансы - все зависит от того, какие еще контейнеры есть на этом хосте и кого туда пускают). --
Re: Запуск гуевых приложений в контейнере
06.06.2020 22:45, Dmitry Alexandrov пишет: Maxim Nikulin wrote: Добавить "#" xhost +si:localuser:#$UID О! Точняк, спасибо. А почему же я этого не нашел, где же это документировано... Xsecurity(7). Только не помню, сам я это нашел по "see also", или попался готовый рецепт. Лень искать или шаманить самому plugin к firefox, который показывает историю по-человечески.
Re: Запуск гуевых приложений в контейнере
Stanislav Vlasov wrote: > иксам пофиг, они вообще от рута запущены. Ну это у кого как. GDM — тот из коробки от пользователя запускает. signature.asc Description: PGP signature
Re: Запуск гуевых приложений в контейнере
06.06.2020, Dmitry Alexandrov<321...@gmail.com> написал(а): Честно говоря, не в курсе, можно ли в контейнерах штатным образом запускать гуёвый софт с отображением его окон на локальных иксах без всяких ssh -X в контейнер >>> >>> Да, естественно, ибо с каких это пор Иксам стали требоваться всякие >>> костыли типа ssh для отрисовки окон на другой машине? Тут вы пишете "на другой машине" >> Ключевые слова - авторизация и шифрование. > > Шифрование трафика виртуальной сети на локалхосте? А авторизация в Иксах > есть, вы же сами про нее ниже пишете. А тут уже спрашиваете про локалхост. Что касается авторизации в иксах - её может и достаточно, но открывать ещё одну дырку для атаки по сети мне как-то не нравится, как и прикрывать её фиговым листочком файрволла. Ноут таскается не только дом-работа. >>> Единственное, я как-то так и не понял, работает ли это с link-local >>> адресами, которые fe80::/10. Кто понял, подскажите. >> >> А чем этот адрес от других ipv6 так сильно отличается > > Тем, что он обязан быть уникальным только в пределах сети второго уровня. А > отсюда какой-нибудь fe80::5054:ff:fed1:a17d — он по-хорошему > fe80::5054:ff:fed1:a17d%virbr0. Два одинаковых макадреса на одной и той же машине - не встречал пока что. Разве что, когда сам ставил. >>> Другое дело, что толку-то? Одних Иксов далеко не всякому гую достаточно. >>> Доступа к отрисовке на GPU Иксы же сами по себе не дают. >> >> Это совершенно другой вопрос - игры и игроподобные вещи > > Да что там игры! У нас даже GTK не прочь отрисовку на GPU заиметь. Хотя > GTK-то, конечно, без него обойдется, а вот, например, видеоплэйер уже нет. Хм... Вот тот же телеграм мне вполне себе показывал видео по ssh до виртуалки с хождением трафика через пару провайдеров. Да и vlc с mplayer ещё умеют вывод на x11. Да, трафик. Да, в полный экран тормозило. Но работало. Так что всё относительно. Совать в контейнер плеер неизвестного происхождения при наличии вполне себе устраивающего локального mpv/vlc - это извращение, по-моему. Впрочем, как и показывать декодированное видео за 7 хопов по обычному инету. >> Скорее, поставить права на .Xauthority (вероятно, через setfacl) + >> пробрасывать данный файл тоже > > Да по-хорошему токен не должен меняться против вашей воли, так можно его > просто и скопировать. Ну или так. Заодно забить на соответствие uid внутри и вне контейнера - файл доступен, сокет доступен, а что uid не соответствует - иксам пофиг, они вообще от рута запущены. -- Stanislav
Re: Запуск гуевых приложений в контейнере
Stanislav Vlasov wrote: > 03.06.2020, Dmitry Alexandrov<321...@gmail.com> написал(а): >>> Честно говоря, не в курсе, можно ли в контейнерах штатным образом запускать >>> гуёвый софт с отображением его окон на локальных иксах без всяких ssh -X в >>> контейнер >> >> Да, естественно, ибо с каких это пор Иксам стали требоваться всякие костыли >> типа ssh для отрисовки окон на другой машине? > > Ключевые слова - авторизация и шифрование. Шифрование трафика виртуальной сети на локалхосте? А авторизация в Иксах есть, вы же сами про нее ниже пишете. > Ну и меньше геморроя - сравните манипуляции с опциями запуска иксов, > потенциально открывающие дыру для всех + xhost и простой запуск ssh -X Да оно понятно. Но раз уж спросили про штатные средства... >> 2. разрешить к нужной инстанции доступ для нужного контейнера: >> >> $ xhost +inet:192.168.122.11 $ xhost +inet6:fd34:fe56:7891:2f3a::11 > > Сразу нет, я как-то не готов давать доступ любому приложению без хотя бы > XAUTH. Я вам, как бы, и не предлагаю. ;-) Мы обсуждали случай, когда у колоименного товарища вся настольная система в контейнере будет. >> Единственное, я как-то так и не понял, работает ли это с link-local >> адресами, которые fe80::/10. Кто понял, подскажите. > > А чем этот адрес от других ipv6 так сильно отличается Тем, что он обязан быть уникальным только в пределах сети второго уровня. А отсюда какой-нибудь fe80::5054:ff:fed1:a17d — он по-хорошему fe80::5054:ff:fed1:a17d%virbr0. > в этом месте? А конкретно в этом месте оно у меня в свое время просто не заработало. А не-link-local — заработал. Возможно, это связано, возможно — нет. >> Другое дело, что толку-то? Одних Иксов далеко не всякому гую достаточно. >> Доступа к отрисовке на GPU Иксы же сами по себе не дают. > > Это совершенно другой вопрос - игры и игроподобные вещи Да что там игры! У нас даже GTK не прочь отрисовку на GPU заиметь. Хотя GTK-то, конечно, без него обойдется, а вот, например, видеоплэйер уже нет. > Скорее, поставить права на .Xauthority (вероятно, через setfacl) + > пробрасывать данный файл тоже Да по-хорошему токен не должен меняться против вашей воли, так можно его просто и скопировать. signature.asc Description: PGP signature
Re: Запуск гуевых приложений в контейнере
Victor Wagner wrote: > В Wed, 03 Jun 2020 10:29:54 +0300 Dmitry Alexandrov <321...@gmail.com> пишет: >> 1. Включить ‘-listen tcp’ у Икс-сервера. Как — см. в документации экранного >> диспетчера, который его собственно по-умолчанию и отключает. > > Ага, а потом еще убедиться, что это надежно заткнуто файрволлом и пустят туда > только из контейнера, а не изо всей локальной сети. Ну, вообще-то там аутентификация есть, и сломанной она, вроде как не считается. Ну а так — естественно, что файерволл к любому серверу не помешает. И вы, конечно, правы, стоит иногда напоминать о его существовании явно. > Лучше уж как ниже описано смонтировать в контейнер юникс-домен сокеты из > /tmp/.X11-unix Смотря в каком случае. В том, с какого мы начали — когда почти вся настольная система засунута в контейнер — да. А в другом — управлять доступом непонятно как: соединения от локальных отличаться перестают совсем. > В принципе, в сочетании с предыдущим советом достаточно просто ~/.Xauthority > в контейнер скопировать. Потому что при этом значение DISPLAY внутри и > снаружи будет совпадать, и магическое печенье подойдет. Если «предыдущий совет» — это про прокинуть сокет, то, как я и написал ниже, при обычных умолчаниях аутентификация пройдет по UIDʼу и безо всякого токена («магического печенья»). >> Авторизация на Икс-сервере будет по UIDʼу, так что если не совпадают, > > А вот не стоит делать так, чтобы не совпадали. Есть куча разных причин по > которым лучше uid-ы синхронизировать Да, конечно. Просто это не всегда подходит по смыслу. signature.asc Description: PGP signature
Re: Запуск гуевых приложений в контейнере
Maxim Nikulin wrote: > 03.06.2020 14:29, Dmitry Alexandrov пишет: >> Авторизация на Икс-сервере будет по UIDʼу, так что если не совпадают, то >> надо явно разрешить, причем я не знаю, как это сделать не давая UIDʼу имя на >> хосте, чтобы мочь приказать: >> $ xhost +si:localuser:stanislav >> >> Кто знает, подскажите. > > Добавить "#" > > xhost +si:localuser:#$UID О! Точняк, спасибо. А почему же я этого не нашел, где же это документировано... > https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ Мерси, подшил. signature.asc Description: PGP signature
Re: Запуск гуевых приложений в контейнере
03.06.2020 14:29, Dmitry Alexandrov пишет: Авторизация на Икс-сервере будет по UIDʼу, так что если не совпадают, то надо явно разрешить, причем я не знаю, как это сделать не давая UIDʼу имя на хосте, чтобы мочь приказать: $ xhost +si:localuser:stanislav Кто знает, подскажите. Добавить "#" xhost +si:localuser:#$UID Мне вариант с пробросом сокета нравится больше, чем открывать доступ по сети (уж лучше через ssh туннель). Есть серия статей, где и про GUI упомянуто. Только с тех пор немного поменялись имена параметров. LXC 1.0: GUI in containers [9/10] https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
Re: Запуск гуевых приложений в контейнере (was: Debian 7 и intel hd graphics 500)
В Wed, 03 Jun 2020 10:29:54 +0300 Dmitry Alexandrov <321...@gmail.com> пишет: > Stanislav Vlasov wrote: > > Честно говоря, не в курсе, можно ли в контейнерах штатным образом > > запускать гуёвый софт с отображением его окон на локальных иксах > > без всяких ssh -X в контейнер > > Да, естественно, ибо с каких это пор Иксам стали требоваться всякие > костыли типа ssh для отрисовки окон на другой машине? > > > простым конфигурированием контейнера. > > Скорее уж хоста. А конкретно: Вот лучше контейнера. Ибо безопаснее будет в нашу параноидальную эпоху. > 1. Включить ‘-listen tcp’ у Икс-сервера. Как — см. в документации > экранного диспетчера, который его собственно по-умолчанию и отключает. Ага, а потом еще убедиться, что это надежно заткнуто файрволлом и пустят туда только из контейнера, а не изо всей локальной сети. Лучше уж как ниже описано смонтировать в контейнер юникс-домен сокеты из /tmp/.X11-unix > 2. разрешить к нужной инстанции доступ для нужного контейнера: > > $ xhost +inet:192.168.122.11 > $ xhost +inet6:fd34:fe56:7891:2f3a::11 Ой, не рекомендую использовать xhost. В принципе, в сочетании с предыдущим советом достаточно просто ~/.Xauthority в контейнер скопировать. Потому что при этом значение DISPLAY внутри и снаружи будет совпадать, и магическое печенье подойдет. > Другое дело, что толку-то? Одних Иксов далеко не всякому гую > достаточно. Доступа к отрисовке на GPU Иксы же сами по себе не дают. > Вот-вот > Если ее надо, то придется проламывать стенку контейнера. На примере > LXC (строчки из configʼа): > > lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none > bind,optional,create=dir,ro lxc.cgroup.devices.allow = c 226:* rwm > lxc.mount.entry = /dev/dri dev/dri none > bind,optional,create=dir lxc.cgroup.devices.allow = c 116:* rwm > lxc.mount.entry = /dev/snd dev/snd none > bind,optional,create=dir > > Первая строчка заменяет сетевую прозрачность Иксов, четвертая-пятая — > Пульсы, ну а вторая-третья — это про тот самый доступ к графике. 226 > и 116 — это мажорные номера устройств, см. ‘$ ls -l /dev/dri/’ в > колонке размера. > > Авторизация на Икс-сервере будет по UIDʼу, так что если не совпадают, А вот не стоит делать так, чтобы не совпадали. Есть куча разных причин по которым лучше uid-ы синхронизировать, и это отнюдь не толко доступ к X-ам. Это еще по крайней мере кардинально упрощает обмен файлами с контейнером. А то опять окажется что ssh проще. --
Re: Запуск гуевых приложений в контейнере (was: Debian 7 и intel hd graphics 500)
03.06.2020, Dmitry Alexandrov<321...@gmail.com> написал(а): >> Честно говоря, не в курсе, можно ли в контейнерах штатным образом >> запускать гуёвый софт с отображением его окон на локальных иксах без >> всяких ssh -X в контейнер > > Да, естественно, ибо с каких это пор Иксам стали требоваться всякие костыли > типа ssh для отрисовки окон на другой машине? Ключевые слова - авторизация и шифрование. Ну и меньше геморроя - сравните манипуляции с опциями запуска иксов, потенциально открывающие дыру для всех + xhost и простой запуск ssh -X >> простым конфигурированием контейнера. > > Скорее уж хоста. А конкретно: > > 1. Включить ‘-listen tcp’ у Икс-сервера. Как — см. в документации экранного > диспетчера, который его собственно по-умолчанию и отключает. > > 2. разрешить к нужной инстанции доступ для нужного контейнера: > > $ xhost +inet:192.168.122.11 > $ xhost +inet6:fd34:fe56:7891:2f3a::11 Сразу нет, я как-то не готов давать доступ любому приложению без хотя бы XAUTH. > Единственное, я как-то так и не понял, работает ли это с link-local > адресами, которые fe80::/10. Кто понял, подскажите. А чем этот адрес от других ipv6 так сильно отличается в этом месте? По ssh ходить на него точно можно. > Другое дело, что толку-то? Одних Иксов далеко не всякому гую достаточно. > Доступа к отрисовке на GPU Иксы же сами по себе не дают. Это совершенно другой вопрос - игры и игроподобные вещи желательно вообще в отдельном компе, вероятно. > Кто знает, подскажите. Скорее, поставить права на .Xauthority (вероятно, через setfacl) + пробрасывать данный файл тоже вместе с установкой переменной окружения. -- Stanislav P.S. Ваше сообщение упало в спам почему-то.
Re: Запуск гуевых приложений в контейнере (was: Debian 7 и intel hd graphics 500)
Stanislav Vlasov wrote: > Честно говоря, не в курсе, можно ли в контейнерах штатным образом запускать > гуёвый софт с отображением его окон на локальных иксах без всяких ssh -X в > контейнер Да, естественно, ибо с каких это пор Иксам стали требоваться всякие костыли типа ssh для отрисовки окон на другой машине? > простым конфигурированием контейнера. Скорее уж хоста. А конкретно: 1. Включить ‘-listen tcp’ у Икс-сервера. Как — см. в документации экранного диспетчера, который его собственно по-умолчанию и отключает. 2. разрешить к нужной инстанции доступ для нужного контейнера: $ xhost +inet:192.168.122.11 $ xhost +inet6:fd34:fe56:7891:2f3a::11 Единственное, я как-то так и не понял, работает ли это с link-local адресами, которые fe80::/10. Кто понял, подскажите. Короче говоря, от того, что у вас за система контейнеризации, все это не зависит никак, внутри только ‘DISPLAY=_gateway:0’ (ну или что надо) экспортировать. Другое дело, что толку-то? Одних Иксов далеко не всякому гую достаточно. Доступа к отрисовке на GPU Иксы же сами по себе не дают. Если ее надо, то придется проламывать стенку контейнера. На примере LXC (строчки из configʼа): lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir,ro lxc.cgroup.devices.allow = c 226:* rwm lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir lxc.cgroup.devices.allow = c 116:* rwm lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir Первая строчка заменяет сетевую прозрачность Иксов, четвертая-пятая — Пульсы, ну а вторая-третья — это про тот самый доступ к графике. 226 и 116 — это мажорные номера устройств, см. ‘$ ls -l /dev/dri/’ в колонке размера. Авторизация на Икс-сервере будет по UIDʼу, так что если не совпадают, то надо явно разрешить, причем я не знаю, как это сделать не давая UIDʼу имя на хосте, чтобы мочь приказать: $ xhost +si:localuser:stanislav Кто знает, подскажите. signature.asc Description: PGP signature
