X.Org Server 21.1.0

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

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

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

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

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

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

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

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

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

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

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, читалки экрана и т.п.?

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

Orca в гноме работае с gtk, но багов хватает.

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

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

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

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

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

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

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

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

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

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

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

Круто, но

не через SUID же,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ssh -X somehost someprog в Wayland осуществить можно?
• setxkbmap -option ctrl:swapcaps в Wayland осуществить можно?

firkax, Rootlexx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я ничего не предлагаю. Я задал вопрос =)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кому нужно?

https://ru.wikipedia.org/wiki/Среда_рабочего_стола

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

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

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

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

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

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

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

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

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

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

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

MS Teams не работает в браузерах под Linux. У меня не заработал.

Ищи ошибку на своей стороне. Всё работает без бубна. Хром, Дебиан 10

Кому нужно?

Вредителям. Им всё надо сломать, переделывать API в каждой новой версии и вообще заниматься ИБД.

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

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

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

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

Тьфу.

Похоже тут вообще никто не слышал, что такое 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 не получают внимания и развития, к сожалению. И запроса как-то нет. Вспоминают об этом все, когда споры начинаются, но реально никто не использует.

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

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

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

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

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

Помню такое, экспериментировал давно. Было бы любопытно подробнее ознакомиться, да всё некогда.

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

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

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

Так пользователи и породили спрос на все современные фичи, которые невозможно реализовать в иксах.

заниматься ИБД

хрюйку

пощади, человек-анекдот

закрыли дыры в захвате ввода/картинки и блокировке экрана

Вы хотели сказать не осилили реализовать.

В базовом протоколе этого и не должно быть. А за его пределами спокойно реализовано/реализовывается.

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

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

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

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

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

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

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

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

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