LINUX.ORG.RU

X.Org Server 21.1.0

 , , ,


3

1

Спустя три с половиной года с момента выхода последней значительной версии состоялся релиз X.Org Server 21.1.0. Изменена система нумерации версий: теперь первая цифра означает год, вторая порядковый номер крупного релиза в году, а третья — корректирующее обновление.

Из значительных изменений можно выделить следующие:

  • В xvfb добавлена поддержка 2D-ускорения Glamor.

  • Добавлена полноценная поддержка системы сборки Meson. В следующей значительной версии будет удалена поддержка сборки с помощью autotools.

  • Появилась поддержка XInput 2.4, дающая возможность использования управляющих жестов на тачпадах.

  • XWayland теперь выпускается в качестве отдельного пакета со своим собственным циклом разработки.

Также сделан ряд небольших изменений и исправлений.

>>> Подробности



Проверено: hobbit ()

Ответ на: комментарий от emorozov

При этом, не знаю, как с записью экрана под Wayland в Zoom, но оооочень сильно сомневаюсь, что он заработает в MS Teams.

Если они используют последнюю версию Electron, то должно работать, ибо там включена поддержка PipeWire по умолчанию.

Но скорее всего, не используют. Со временем перелезут, конечно, как и все остальные, но пока вот так.

Rootlexx ★★ ()
Ответ на: комментарий от firkax

программа пытается (зачем-то) открывать /dev/sda

Работа с реальными разделами от неё не требуется, от неё вообще не требуется работа с разделами, а требуется какой-то другой функционал

И вы ещё меня упрекали в чрезмерном теоретизировании…

Речь, вообще-то, шла о программах, которым нужна запись с экрана, и которые при возврате мусорных данных «сломаются» — при чём здесь ваш пример, категорически непонятно.

Ну и спрошу ещё раз:

Авторизация уже есть (системная по uid)

Можно поподробнее? Вы собрались запрещать доступ по UID?

Rootlexx ★★ ()
Ответ на: комментарий от anonymous

BadAccess в большинстве случаев возвращается, надо учиться его обрабатывать

Во-первых, для многих запросов возврат ошибки Access не предусмотрен. О том и речь, что нужно изменять протокол.

Во-вторых, в протоколе, опять же, чётко описано, что означает ошибка Access:

Access  An attempt is made to grab a key/button combination already
        grabbed by another client.
        An attempt is made to free a colormap entry not allocated by the
        client or to free an entry in a colormap that was created with all
        entries writable.
        An attempt is made to store into a read-only or an unallocated colormap entry.
        An attempt is made to modify the access control list from other than
        the local host (or otherwise authorized client).
        An attempt is made to select an event type that only one client can
        select at a time when another client has already selected it.

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

Permission Denied не смущает же программу файлового менеджера, которая лезет например к чужим файлам, она при этом не сваливает, чем здесь не так?

Не смущает, потому что эта ошибка описана для используемых функций операций с файлами.

У меня вообще вопрос а как в вяленом c a11y, т.е. с accessibility, читалки экрана и т.п.?

Честно говоря, без понятия.

Rootlexx ★★ ()
Ответ на: комментарий от Rootlexx

Речь, вообще-то, шла о программах, которым нужна запись с экрана, и которые при возврате мусорных данных «сломаются» — при чём здесь ваш пример, категорически непонятно.

Программы, которым на самом деле нужна запись с экрана, следует доработать - они должны уметь выдавать пользователю сообщение о том, что им не хватает прав. До тех пор, пока они это не умеют, никакие фокусы с протоколом не помогут.

Хотя есть другой вариант: такое сообщение может выдавать WM по нотификации от X-сервера. WM, разумеется, тоже надо будет доработать чтобы он это поддерживал, но это, возможно проще, чем разыскивать мэйнтейнеров всего софта из какого-нить 2000 года, когда вышла последняя его версия. Ну то есть, программа шлёт неавторизованное XGetImage, X-сервер шлёт уведомление об этом window manager'у (программе ничего не отвечает), а тот в свою очередь показывает юзеру сообщение о том, что произошёл такой запрос и надо либо разрешнить его, либо запретить. Если же прога будет показывать чёрный квадрат после явного запрета - это уже точно багом никто не посчитает.

Можно поподробнее? Вы собрались запрещать доступ по UID?

Запрещать доступ не по uid смысла нет. Потому что злонамеренная программа с тем же uid-ом запросто установит свой хук в нужный процесс (которому выдали права) и сделает всё что надо от его имени. Для изоляции данных процессов друг от друга давным давно придумали uid-ы, их и надо использовать. И, кстати, если X-сервер запущен от того же юзера (и не setuid) то злонамеренная программа может прямо из него всё прочитать, вообще минуя протоколы.

firkax ()
Ответ на: комментарий от firkax

Запрещать доступ не по uid смысла нет. Потому что злонамеренная программа с тем же uid-ом запросто установит свой хук в нужный процесс (которому выдали права) и сделает всё что надо от его имени

Для этого есть механизмы изоляции через пространства имён, типа bubblewrap. См. flatpak.

И, кстати, если X-сервер запущен от того же юзера (и не setuid) то злонамеренная программа может прямо из него всё прочитать, вообще минуя протоколы.

X-сервер обычно запускается в контролируемом окружении, поэтому не сможет.

При этом если на каждую роль использовать по отдельному UID, то, во-первых, непонятно, как под этими UID запускать — не через SUID же, — а во-вторых, те же сохранённые снимки экрана или записи захвата будут иметь другого владельца, что помешает пользователю получить к этим файлам полный доступ.

Rootlexx ★★ ()
Ответ на: комментарий от Rootlexx

Для этого есть механизмы изоляции через пространства имён, типа bubblewrap. См. flatpak.

Круто, но

не через SUID же,

там внутри тоже suid. Так что определись допускается он или нет.

X-сервер обычно запускается в контролируемом окружении, поэтому не сможет.

Каком таком контролируемом? А кто в неконтролируемом тогда? Хотя это не сильно важно, сервер то один, с ним можно что-то и придумать централизованно.

те же сохранённые снимки экрана или записи захвата будут иметь другого владельца, что помешает пользователю получить к этим файлам полный доступ.

Ну так, если у них будет тот же владелец - то прога из под этого владельца сможет их украсть (из файлов). Есть такое понятие - security boundary - так вот, если в ней где-то есть дыра, то все «охранные» мероприятия по остальному периметру становятся бесполезны. Нельзя приложение с одной стороны изолировать, а с другой, в целях удобства, не изолировать - это тоже самое что не изолировать вовсе.

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

Так вот, если ты опасаешься какой-то проги, то изолировать её надо не только в иксах, но и в системе вообще, в том числе у неё не должно быть прямого неограниченного доступа к $HOME. Самый простой способ этого добиться - запускать её другим uid-ом (при этом способов контролируемо шарить файлы между этой прогой и $HOME полно, не в них суть). Автоматически это же даст возможность и авторизовать её в иксах. Ну, можно конечно и контейнер использовать, но это уже другая тема. Если ты не готов идти на такие (небольшие) жертвы, то забудь про безопасность, она тебе всё равно не грозит.

firkax ()
Ответ на: комментарий от firkax

там внутри тоже suid

$ stat -c '%A (%a)' /usr/bin/bwrap 
-rwxr-xr-x (755)

Это только если user namespaces в ядре отключены — тогда нужен SUID.

Каком таком контролируемом?

Его обычно запускает display manager, которому уже окружение не подменишь.

Ну так, если у них будет тот же владелец - то прога из под этого владельца сможет их украсть (из файлов).

Если пользователь сможет прочитать файлы снимков, сделанные под другим UID, — а он должен, иначе в чём смысл? — то никакой разницы.

Речь-то шла не о таких сценариях (от них механизмы защиты в виде контейнеризации уже есть), а о тех, когда программа втихую без ведома пользователя делает снимки экрана. X11 позволяет ей это делать даже из контейнера.

Так вот, если ты опасаешься какой-то проги, то изолировать её надо не только в иксах, но и в системе вообще

Спасибо, что рассказали мне то, о чём я вообще-то уже писал.

Суть в том, что при текущей системе можно хоть трижды упаковать программу в контейнер, но если у неё есть доступ к X-серверу, который ничтоже сумняшеся отдаёт все данные и события, то толку от такой изоляции не будет. Поэтому нужна изоляция плюс электрификация всей контроль доступа со стороны графической системы.

Rootlexx ★★ ()
Ответ на: комментарий от Rootlexx

Если пользователь сможет прочитать файлы снимков, сделанные под другим UID, — а он должен, иначе в чём смысл? — то никакой разницы.

Пользователь, в смысле человек, пользующийся компом - должен смочь (каким-то удобным способом). А вот любой запущеный им софт - уже совсем не должен. Например, браузер не должен, если только пользователь не захочет их отправить куда-то через веб.

Я не пойму что ты пытаешься доказать. С тем, что текущая реализация иксов не изолирует друг от друга своих клиентов - никто не спорил. Аргументов против моего первоначального заявления о том, что эту изоляцию вполне можно реализовать в рамках имеющейся системы почти без жертв (заметных обратных несовместимостей), и что работа на таких чуть-чуть усовершенствованных иксах в плане изоляции ничем вейланду уступать не будет - ты не приводишь. О чём тогда спор?

firkax ()
Ответ на: комментарий от firkax

Пользователь, в смысле человек, пользующийся компом - должен смочь (каким-то удобным способом). А вот любой запущеный им софт - уже совсем не должен. Например, браузер не должен, если только пользователь не захочет их отправить куда-то через веб.

И как вы собрались это реализовать? Через ACL?

И да: в вашей схеме для каждого пользователя будет своё множество UID (по одному для роли) — ну такое себе. Уж лучше использовать другой механизм авторизации, а ещё лучше — SELinux и мандатный доступ.

Я не пойму что ты пытаешься доказать

Для начала попробуйте определиться, с каким из моих тезисов вы вообще спорите. А то мне тоже непонятно. Я вроде никогда не отрицал, что путём изменений в протоколе можно добиться большего контроля доступа к чувствительным с точки зрения безопасности запросам — более того, я именно об этом писал.

Rootlexx ★★ ()
Ответ на: комментарий от Rootlexx

И как вы собрались это реализовать? Через ACL?

И да: в вашей схеме для каждого пользователя будет своё множество UID (по одному для роли) — ну такое себе. Уж лучше использовать другой механизм авторизации, а ещё лучше — SELinux и мандатный доступ.

Тут нет чётких границ между разными способами всё это делать. Но доступ, как ни крути, в итоге получится примерно мандатный - потому что суть задачи сводится по факту к нему. С «много uid» не вижу проблем, давно такое использую (правда там и иксы отдельные) - для основных действий один аккаунт, для сомнительного доверия игр (в т.ч. wine+steam) ещё несколько разных (не знаю какая из них может оказаться источником проблем - пусть не заденет соседей), для экспериментов с биткоинами ещё один, и т.д. И польза тут не только в изоляции для безопасности, а ещё и в том что у каждого юзера $HOME не засорён рандомными файлами. Выводить всё жир в общие иксы обычно как раз не нужно (просто переключение воркспейсов Ctrl+Alt+Fn), чаще нужно шарить файлы, увы, костылями.

firkax ()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от EmgrtE

Поэтому кто до сих пор использует иксы и не планирует переходить на вяленого, напишите, пожалуйста ваши «за» в сторону иксов.

  • ssh -X somehost someprog в Wayland осуществить можно?
  • setxkbmap -option ctrl:swapcaps в Wayland осуществить можно?
dexpl ★★★★★ ()
Ответ на: комментарий от Rootlexx

Любой софт будет так себя вести. Чтобы правильно обработать дополнительно появившийся код ошибки отказа в доступе (т.е. вывести сообщение пользователю), необходимо иметь code path для этого, что требует модификации программ.

Не смущает, потому что эта ошибка описана для используемых функций операций с файлами.

Можно вспомнить такой пример, что под Windows большинство программ сначала вообще не предполагали, что могут получить отказ доступа (Сначала Win3.x, потом Win9x, все дела. На NT мало что тестировалось.)

А потом не предполагали, что могут получить отказ доступа во вполне определённых каталогах, не предназначенных для этого производителем ОС.

И ничего, большая часть приложений была постепенно либо исправлена, либо заменена аналогами, либо их можно как-то с костылями запустить.

И предложение о замене протокола полностью вместо доработки - это как если бы в Windows заменили весь файловый API. Что очевидная нелепица.

wandrien ()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от dexpl

Ремап клавиш можно Хотя бы тут по поиску вбить Wayland: Как поменять две клавиши местами? (комментарий)

Для удаленного запуска костыли тоже есть например Waypipe

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

anonymous ()
Ответ на: комментарий от Rootlexx

Предлагаете заодно и QueryTree сломать? 🙂

Хм. А кто вам сказал, что разные клиенты, подключаясь на сокет X-сервера, обязаны попадать на ОДИН И ТОТ ЖЕ сервер? Это деталь реализации вообще-то.

wandrien ()
Ответ на: комментарий от Rootlexx

программа (которой мы не доверяем) пытается открыть /dev/sda и падает если не получается. Решение: даём ей фейковый sda (наверно с фейковой таблицей разделов, а вот остальное нули), так она не упадёт.

…но и не будет работать с реальными разделами, и с точки зрения пользователя будет сломана. Разработчиков ждёт немало увлекательных багрепортов!

То есть ли я как админ компа подсуну программе фейковый /dev/sda, то разрабы программы несут за это ответственность? Ну вы даёте.

wandrien ()
Ответ на: комментарий от firkax

С «много uid» не вижу проблем, давно такое использую (правда там и иксы отдельные) - для основных действий один аккаунт, для сомнительного доверия игр (в т.ч. wine+steam) ещё несколько разных (не знаю какая из них может оказаться источником проблем - пусть не заденет соседей), для экспериментов с биткоинами ещё один, и т.д.

Вы так и не написали, как вы запускаете программы под другими пользователями — sudo, или просто заходите вручную?

Если запускать тот же GIMP под отдельным пользователем лишь потому, что он может сделать снимок экрана, то как открывать в нём произвольные изображения из самых разных пользовательских каталогов? То же касается и видеоредакторов, и даже VLC (ибо он умеет захват экрана). Выглядит пока что как куча лишних телодвижений.

На мой взгляд, подход того же flatpak намного удобнее: и программы запускаются от вашего пользователя, но изолированно, и домашний каталог у них может быть свой (в ~/.var/), и доступ к любым файлам есть через порталы (что требует явного действия от пользователя, и потому безопасно).

Ну и создавать кучу UID для каждого реального пользователя… Уж лучше группы тогда использовать, наверное, а не отдельные UID.

Rootlexx ★★ ()
Ответ на: комментарий от wandrien

И ничего, большая часть приложений была постепенно либо исправлена, либо заменена аналогами, либо их можно как-то с костылями запустить.

А теперь примените эту фразу к стенаниям о проблемах при переходе на Wayland. 😉

И предложение о замене протокола полностью вместо доработки

Разработчики Wayland вроде не указывали безопасность как единственную причину, разве не так?

Rootlexx ★★ ()
Ответ на: комментарий от Rootlexx

А теперь примените эту фразу к стенаниям о проблемах при переходе на Wayland.

Не получается применить, извините.

Доработка приложения в случае с виндой сводилась к частной подгонке под требования SDK. Не писать конфиги в установочный каталог и т.п.

Переход на вейланд для многих приложений это переписывание солидных кусков и подсистем и последующий многолетний их дебаг.

wandrien ()
Ответ на: комментарий от wandrien

Хм. А кто вам сказал, что разные клиенты, подключаясь на сокет X-сервера, обязаны попадать на ОДИН И ТОТ ЖЕ сервер? Это деталь реализации вообще-то.

Ага, предлагаете сломать ещё и DnD? 🙂

Rootlexx ★★ ()
Ответ на: комментарий от wandrien

То есть ли я как админ компа подсуну программе фейковый /dev/sda, то разрабы программы несут за это ответственность? Ну вы даёте.

Вы, видимо, не очень внимательно читали тему. Речь изначально шла о тихом подсовывании некорректных данных в случае ошибки доступа вместо возврата собственно ошибки. В таком случае пользователем работа такой программы будет воспринята как некорректная, и разработчикам посыпятся багрепорты. Пример с приложением захвата экрана, запущенном под Xwayland, я уже приводил.

Rootlexx ★★ ()
Ответ на: комментарий от wandrien

Переход на вейланд для многих приложений это переписывание солидных кусков и подсистем и последующий многолетний их дебаг.

Не для многих, а для отдельных. Большинство приложений не делает снимки экрана, не производит его захват и т.д. А остальное за них делает тулкит.

Rootlexx ★★ ()
Ответ на: комментарий от Rootlexx

Я считаю. что такой режим вполне может включаться на дисплейном сервере, например, в целях отладки или под локальные задачи и требования. Самим пользователем.

А нормальный режим должен быть такой:

  • У на есть протокол следующего поколения, назовём его условно X11next. В нём предусмотрены расширенные средства управления доступом. Если приложение подключается по нему, то работа осуществляется в полной логике соответствующих подсистем ОС. (например, запрос привелегий средствами полкит-агента и т.п.)

  • У нас есть старый протокол X11. Если приложение подключается по нему и пытается делать то, на что у него нет прав, то оно получает отлуп, возможный в рамках протокола. (Другой код ошибки или пустые данные вместо фактических.) А пользователю средствами отдельного вспомогательного процесса показывают большой message box, мол, «В приложении ПриветМедвед обнаружены проблемы совместимости с НашейЗамечательнойОС в связи с использованием устаревшего протокола, и оно может работать некорректно. Пожалуйста обновите приложение или обратитесь за дальнейшей поддержкой к разработчику приложения.»

И пользователь, видя это сообщение, идёт в багтрекер ПриветМедведа и жалуется там уже не на «черный экран», а конкретно: «Ваша штука не работает в новой Убунте! Написано, что вы несовместимы! Исправьте!!1»

И все счастливы.

wandrien ()
Последнее исправление: wandrien (всего исправлений: 3)
Ответ на: комментарий от Rootlexx

Не для многих, а для отдельных. Большинство приложений не делает снимки экрана, не производит его захват и т.д. А остальное за них делает тулкит.

Угу, тулкит. Плавали, знаем. Тот же gtk настолько убог, что приходилось таскать с собой его переписанные куски.

wandrien ()
Ответ на: комментарий от Rootlexx

firkax правильно говорит: для приложений старого протокола отлуп должен быть максимально нетравмирующий. Пустые данные, фейковые события и т.п.

Это для того, чтобы оно не сегфолтнулось и не грохнуло несохранённые пользовательские данные.

Но делать это нужно не скрыто, а предупреждая пользователя о происходящем: ПРИЛОЖЕНИЕ НЕСОВМЕСТИМО. Так и писать.

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

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

wandrien ()
Ответ на: комментарий от Rootlexx

Вы так и не написали, как вы запускаете программы под другими пользователями

Если речь про то что по факту есть сейчас то я написал: там и иксы отдельные, и переключение по Ctrl-Alt-Fn между рабочими столами разных юзеров, вобщем-то единственное неудобно это костыльный шаринг файлов, который иногда нужен.

Как нужно в идеале - не знаю точно. Очевидно, для этого нужен доп. софт. Контейнеры - тоже доп. софт, но на мой взгляд там слишком много лишнего по сравнению с обычным разделением по uid (к которому можно даже файрволл настроить, если что, так что контейнеризация сети тоже необязательна).

Выглядит пока что как куча лишних телодвижений.

Ну речь не про gimp шла, он то вобщем-то доверенный софт. А так - да, доп. усилия надо прилагать, но не такие и большие если всё нормально оформить. Вручную вводить кучу команд точно не надо.

На мой взгляд, подход того же flatpak намного удобнее: и программы запускаются от вашего пользователя, но изолированно, и домашний каталог у них может быть свой (в ~/.var/), и доступ к любым файлам есть через порталы (что требует явного действия от пользователя, и потому безопасно).

В чём суть запуска «от вашего пользователя» если там всё изолировано? Тогда уж и uid сменить чтобы удобнее отличать процессы. А вообще я выше написал, контейнеры тоже допустимы, но они делают лишнее.

Ну и создавать кучу UID для каждого реального пользователя… Уж лучше группы тогда использовать, наверное, а не отдельные UID.

Реальный пользователь по факту обычно один, и все uid-ы, в том числе системные - его. И с системными uid-ами давным давно (или всегда) было понимание что каждому демону лучше создать свой по возможности (вместо одного юзера «SYSTEM» на всё в винде), а вот с пользовательскими почему-то аналогию не сделали.

firkax ()
Ответ на: комментарий от wandrien

И зачем это всё, если и X.Org, и X11 в любом случае нужно закапывать?

Приложения и так могут продолжать через XWayland работать. И чтобы снова можно было экран захватывать, достаточно добавить поддержку правильных API (которые и в иксовой сессии работать будут). Эффект для разработчиков софта тот же получается, но при этом не предотвращается переход на нормальный графический стек.

sudopacman ★★★★★ ()
Ответ на: комментарий от wandrien

Вы не поверите, но почти так и есть, только протокол назвали не X11next, а сами-знаете-как. 😉 Но что-то счастливы не все.

Ваш подход столкнётся ровно с тем же неприятием и отторжением определённой категории пользователей, что и Wayland. «Вы сломали мой X-сервер».

И уведомления, которые вы предлагаете, будут их только сильнее раздражать: «Всё десятилетиями работало, а тут пришли смузихлёбы и всё сломали! И им ещё хватает наглости называть мою прелесть — божественный X11 — устаревшим! Пойду напишу гневный пост на LOR…»

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

Такова судьба всех ломающих изменений, даже если они ломают лишь малую часть используемого ПО. 🤷

Rootlexx ★★ ()
Ответ на: комментарий от wandrien

Угу, тулкит. Плавали, знаем. Тот же gtk настолько убог, что приходилось таскать с собой его переписанные куски.

Какое отношение гипотетическая убогость GTK имеет к его Wayland-бэкенду? Не нравится GTK — возьмите Qt, Wayland-то тут при чём?

Rootlexx ★★ ()
Ответ на: комментарий от firkax

В чём суть запуска «от вашего пользователя» если там всё изолировано?

В том, что если разрешить доступ к определённым каталогам (как чаще всего и бывает), а также при открытии/сохранении файлов через порталы — не будет проблем с доступом из-за различающихся UID.

Реальный пользователь по факту обычно один, и все uid-ы, в том числе системные - его.

Вот не надо этого, пожалуйста.

Rootlexx ★★ ()
Ответ на: комментарий от anonymous

Да и вообще программ которым надо что-то нарушать (иметь роли) не наберется больше пары десятков, ничего не стоит их доделать, чтоб выдавали осмысленное предупреждение, а не тихо сваливали, если вообще есть такие.

Хотя бы пару таких программ кто-нибудь продемонстрирует?

anonymous ()
Ответ на: комментарий от Rootlexx

Во-первых, для многих запросов возврат ошибки Access не предусмотрен. О том и речь, что нужно изменять протокол.

Для подавляющего большинства вызовов метки XACE уже проставлены. Но ты такой рьяный собрался менять протокол.

Тьфу.

anonymous ()
Ответ на: комментарий от anonymous

Похоже тут вообще никто не слышал, что такое XACE (хуки на действия) и Xselinux (решающие правила).

Нет, ну, слышали, конечно. Некоторые :)

Color Picker 1.0 — свободный десктопный редактор палитр (комментарий)

Сливы от Xorg (комментарий)

XSELINUX вроде даже человек из NSA занимался - Eamon Walsh.

Есть еще более простой двухуровневый механизм X Security Extension, там только trusted/untrusted. Приложения, которые хотят чего-то получить вне себя, могут запросто вылететь. Вот берем gpick, который по всему дисплею может цвета получать. Просто запускаем - работает. Но не секурно же - ворует цвета! :) Делаем секурно, но софт превращается в ничто. Сделаем cookie на 10 минут.

$ xauth -f untrusted_magick_cookie generate :0 MIT-MAGIC-COOKIE-1 untrusted timeout 6000
$ XAUTHORITY=untrusted_magick_cookie gpick
(gpick:14692): Gdk-ERROR **: 16:42:22.863: The program 'gpick' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 1700 error_code 10 request_code 62 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Ловушка трассировки/останова

Делаем scrot (фотографирую экран)

$ XAUTHORITY=untrusted_magick_cookie scrot 
X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  104 (X_Bell)
  Serial number of failed request:  6
  Current serial number in output stream:  8

Все эти вещи - XACE с XSELINUX, X Security Extention не получают внимания и развития, к сожалению. И запроса как-то нет. Вспоминают об этом все, когда споры начинаются, но реально никто не использует.

Zubok ★★★★★ ()
Ответ на: комментарий от wandrien

Ладно, переформулирую. Нужно тем, кто занимается разработкой графического стека, чтобы обеспечить потребности пользователей, и, соответственно, самим пользователям. Другими словами, всем, кроме активного меньшинства фанатиков-луддитов.

sudopacman ★★★★★ ()
Ответ на: комментарий от sudopacman

Тем, кому надоело сидеть с графической системой из каменного века.

Сообщение удалено leave по причине 4.3 Провокация flame (0)

Другими словами, всем, кроме активного меньшинства фанатиков-луддитов.

Ничему тебя жизнь не учит. Иди делай уроки.

wandrien ()
Ответ на: комментарий от X512

Устранили тиринг, починили масштабирование, частоту обновления и VRR на нескольких мониторах, закрыли дыры в захвате ввода/картинки и блокировке экрана, запилили direct scanout… Вот ведь вредители!

sudopacman ★★★★★ ()
Ответ на: комментарий от sudopacman

тобы обеспечить потребности пользователей, и, соответственно, самим пользователям

А может, пользователь лучше знает, что ему нужно? Вон гномовцы тоже думают, что лучше знают, ты гном 40 видел? Спрос должен рождать предложение, иначе предлагать будут одно говно.

Dog ()
Ответ на: комментарий от sudopacman

Такой базовый протокол годится разве что для встраиваемой техники. По сути Wayland всерьёз только там и используется.

Отсутствие необходимого базиса в протоколе порождает разные несовместимые реализации вроде Mutter и Wlroots и способствует фрагментации экосистемы.

X512 ★★ ()
Ответ на: комментарий от X512

Отсутствие необходимого базиса в протоколе порождает разные несовместимые реализации вроде Mutter и Wlroots и способствует фрагментации экосистемы.

Так ведь дополнительную функциональность тоже стандартизируют в качестве расширений протокола либо в xdg-*, когда оно не специфично для Wayland. Несовместимые реализации и фрагментация и так есть.

Сейчас есть 3 основыне реализации: Mutter, KWin и Wlroots. С Mutter всё понятно, а вот KWin в рамках форка портируют на Wlroots. Если приживётся, то основных реализаций будет уже 2. Есть ещё Mir, интересный полутора анонам. Сейчас для создания композитора нет смысла что-то кроме Wlroots использовать.

Но частично ты прав.

  • Что мешало им сразу сформировать хотя бы черновики для расширений, реализующих функции, необходимые для полноценного десктопа, и постепенно их стабилизировать?

  • Что мешало сделать нормальную WLC, которую не пришлось бы форкать, и использовать её хотя бы частично при портировании Mutter/KWin?

Типичное раздолбайство, распространённое в свободных проектах.

sudopacman ★★★★★ ()