Есть две технологии в ИТ, которые казалось должны были исчезнуть на рубеже прошлого века, но их живучесть и удобство раз за разом отодвигает их уход со сцены. Речь идет об IPv4 и X11. Если первый из них практически во всех аспектах уступает IPv6, то преимущества Wayland, как технологии над X11 очевидны не всем. Wayland вовсе не универсален, как X Windows System, он намного более прост. Это дает ему ряд преимуществ по сравнению с иксами, но в этом же кроются его недостатки.
Если говорить о преимуществах, то это в первую очередь простота реализации и долгожданное избавление пользователей графической среды Linux от таких артефактов перерисовки, как разрывы изображения, a․ k․ a․ tearing. С этим особенно часто сталкиваются обладатели видеокарт NVidia. Хватает и недостатков и противники замены X-сервера напирают на гибкость использования сетевых возможностей в различных сценариях.
As mentioned, X is essentially a networking protocol with graphical displaying capabilities.
На самом деле X11 сетевой протокол с графическими возможностями, а не наоборот. Из этого простого факта следует, что даже если в скором времени основные дистрибутивы Linux перейдут на протокол Wayland, многие из возможностей и примеров использования X сервера будут востребованы еще достаточно долгое время. Удаленный доступ к приложениям и сессиям X.Org — современной реализации X Window System, одна из таких ключевых особенностей системы.
LPIC 106.1 часть первая: Включение графики в Linux или X11
▍ Сетевая структура взаимодействий X-сервера
Наиболее распространенным IPC, т․ е․ способом взаимодействия между процессами, X-клиента и X-сервера, являются сокеты. Их роль в предоставлении API связи с использование TCP/IP, а также сокетов домена Unix. Помимо сокетов клиент и сервер для коммуникации могут также использовать иные каналы IPC, например MIT Shared Memory Extension.
Доменные сокеты Unix (от англ. Unix Domain Sockets, UDS) являются POSIX-механизмом IPC, с помощью которого различные процессы ОС могут взаимодействовать друг с другом. Такие сокеты эффективнее локальных TCP/IP соединений, так как не требуют дополнительных байтов в заголовке протокола. Подобно сокетам TCP/IP, доменные сокеты Unix поддерживают надёжную потоковую передачу данных с помощью SOCK_STREAM. Они также могут работать в режиме упорядоченной ( см․ SOCK_SEQPACKET) и неупорядоченной ( см․ SOCK_DGRAM) передачи датаграмм.
Рис. 1 Сетевое взаимодействие между клиентом и сервером X с помощью UDS.
UDS используют файловую систему ОС в качестве адресного пространства имён (например /tmp/my_xapp ), сами сокеты в ней всего лишь inode, а процессы обращаются к сокетам, так же, как к файлу. Однако обмен данными в активном соединении использует не файловую систему, а только буферы памяти ядра.
X11 Forwarding: Удаленный запуск графических приложений
Рис. 2 Сетевое взаимодействие между клиентом и сервером X поверх TCP/IP.
Сокеты TCP/IP и UDS создаются с помощью функции CreateWellKnownSockets(). Для этого она обращается к _XSERVTransMakeAllCOTSServerListeners . Эта процедура пробегает по каждому интерфейсу транспорта, поддерживаемого сервером.
static Bool TryCreateSocket(int num, int *partial) < char port[20]; snprintf(port, sizeof(port), «%d», num); return (_XSERVTransMakeAllCOTSServerListeners(port, partial, ListenTransConns) >= 0); >
Количество таких интерфейсов определено константой NUMTRANS в файле X11/Xtrans/Xtrans.c.
#define NUMTRANS (sizeof(Xtransports)/sizeof(Xtransport_table))
Таблица Xtransports[] определена в том же самом файле и содержит 10 элементов, таким образом NUMTRANS ≤ 10.
Сами же флаги, которые во время сборки определяют транспортные интерфейсы X сервера, можно найти в xc/config/cf/linux.cf .
#if HasDECnet # define ConnectionFlags -DUNIXCONN -DTCPCONN -DDNETCONN # define ExtraLibraries -ldnet #else # define ConnectionFlags -DUNIXCONN -DTCPCONN #endif
Проследив цепочку до системного вызова socket() находим такую последовательность транспортных процедур.
TRANS(MakeAllCOTSServerListeners) | v +————————-+ +——>TRANS(OpenCOTSServer)+—>|TRANS(SocketSelectFamily)| | | |TRANS(SocketOpen) | | v +——-+——————+ | TRANS(Open) | | | | | v v +——+TRANS(ParseAddress) socket()
Серверный процесс стартует с вызова функции TRANS(CreateListener) из Xtrans.c . Далее переход в состояние ожидания входящего соединения происходит в такой последовательности.
TRANS(MakeAllCOTSServerListeners) | v TRANS(CreateListener) | v TRANS(SocketCreateListener) | v bind()
В файле Xtransmit.h можно обнаружить X_TCP_PORT . Первое клиентское соединение будет использовать порт 6000, второе — 6001 и т․ д․
#define X_TCP_PORT 6000
▍ Взгляд изнутри трафика между клиентом и сервером X
Запустим простейшую иксовую программу Xclock и проверим как все это работает на практике.
В первой строке вывода видим, что системный вызов socket() завершился успешно и вернул файловый десткриптор 3. Далее, во второй строке setsockopt() выставляет параметр TCP_NODELAY , с которым TCP фрагменты отправляются по сети как можно ранее, даже если эти фрагменты слишком малы. В третьей строке опять встречается setsockopt() на это раз для активации опции SO_KEEPALIVE . Данный параметр поддерживает соединение в активном состоянии, с помощью периодической отправки служебных сообщений. Наконец в четвертой строке системный вызов connect() соединяет клиент X с сервером, по TCP порту 6000.
Используемый TCP порт напрямую связан с количеством соединений и номером переменной $DISPLAY , если бы использовалось DISPLAY=tcp/192.168.10.10:1.0 , то тогда в последней строке connect() состоялся бы по TCP порту 6001.
После рукопожатия обмен данными происходит с использованием структур X-клиента — xConnClientPrefix , и X-сервера — xConnSetupPrefix , XconnSetup , определенных в файле /usr/include/X11/Xproto.h . Размер занимаемой памяти в структур в байтах определен в #define директивах заголовочного файла.
#define sz_xConnClientPrefix 12 #define sz_xConnSetupPrefix 8 #define sz_xConnSetup 32 . typedef struct < CARD8 byteOrder; BYTE pad; CARD16 majorVersion, minorVersion; CARD16 nbytesAuthProto; /* Authorization protocol */ CARD16 nbytesAuthString; /* Authorization string */ CARD16 pad2; >xConnClientPrefix; . typedef struct < CARD8 success; BYTE lengthReason; /*num bytes in string following if failure */ CARD16 majorVersion, minorVersion; CARD16 length; /* 1/4 additional bytes in setup info */ >xConnSetupPrefix;
Рис. 3 Установка параметров соединения в сессии X11.
Можно также пронаблюдать за процессом с помощью сетевого анализатора, клиентский запрос Initial connection request соответствует вызову xConnClientPrefix . Соответственно Initial connection reply в следующем пакете создан со стороны xConnSetupPrefix и xConnSetup . Для сбора трафика можно запустить Wireshark и слушать локальный интерфейс, либо с помощью следующей команды tcpdump.
Далее, сам файл можно открыть в Wireshark и отфильтровать просмотр по протоколу x11 . Обычно для сбора трафика нужны привилегии root.
Рис. 4 Сетевой след соединения X11 в WireShark.
То же самое и во всех подробностях можно увидеть в tshark в текстовом формате. Так выглядит клиентский запрос X11 в сторону сервера.
Frame 11: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) Encapsulation type: Ethernet (1) . [Protocols in frame: eth:ethertype:ipv6:tcp:x11] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) . Internet Protocol Version 6, Src: ::1, Dst: ::1 0110 . = Version: 6 . Transmission Control Protocol, Src Port: 49202, Dst Port: 6010, Seq: 1, Ack: 1, Len: 48 Source Port: 49202 Destination Port: 6010 . X11, Request, Initial connection request byte-order: 0x6c (Little-endian) unused protocol-major-version: 11 protocol-minor-version: 0 authorization-protocol-name-length: 18 authorization-protocol-data-length: 16 unused authorization-protocol-name: MIT-MAGIC-COOKIE-1
Пакет с ответом со стороны X-сервера совсем не так лаконичен, в нем указаны все необходимые детали для форматирования графического вывода на экран.
Frame 13: 14698 bytes on wire (117584 bits), 14698 bytes captured (117584 bits) Encapsulation type: Ethernet (1) . [Protocols in frame: eth:ethertype:ipv6:tcp:x11] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) . Internet Protocol Version 6, Src: ::1, Dst: ::1 0110 . = Version: 6 . Transmission Control Protocol, Src Port: 6010, Dst Port: 49202, Seq: 1, Ack: 49, Len: 14612 Source Port: 6010 . X11, Reply, Initial connection reply success: 1 unused protocol-major-version: 11 protocol-minor-version: 0 replylength: 3651 release-number: 12011000 resource-id-base: 0x0b200000 resource-id-mask: 0x001fffff motion-buffer-size: 256 length-of-vendor: 20 maximum-request-length: 65535 number-of-screens-in-roots: 1 number-of-formats-in-pixmap-formats: 7 image-byte-order: 0x00 (LSBFirst) bitmap-format-bit-order: 0x00 (LSBFirst) bitmap-format-scanline-unit: 32 bitmap-format-scanline-pad: 32 min-keycode: 8 max-keycode: 255 unused vendor: The X.Org Foundation pixmap-format pixmap-format . pixmap-format . screen screen (000007a4: 1920 x 1080 x 24) root: 0x000007a4 default_colormap: 0x00000020 white_pixel: 0x00ffffff black_pixel: 0x00000000 current_input_masks: 0x00fa8033 width_in_pixels: 1920 height_in_pixels: 1080 width_in_millimeters: 451 height_in_millimeters: 254 min_installed_maps: 1 max_installed_maps: 1 root_visual: 0x00000021 backing_stores: 0x01 save_unders: False root_depth: 24 allowed_depths_len: 7 depth-detail depth-detail depth: 24 unused visualtypes-numbers: 576 unused visualtype visualtype . visualtype . visualtype .
▍ Удаленное подключение к X-серверу по ssh
Переходя от теории сетевых взаимодействий X Window System к практике, рассмотрим, как запустить графическое приложение на уделенном X-сервере при подключении по ssh.
- Подключение необходимо запускать с ключом -X , который активирует переадресацию X11. На практике, однако из-за X11 SECURITY extension это часто не работает. В таких случаях используют -Y для подключения с доверительной переадресацией X11.
- Убедитесь, что на удаленном сервере установлен пакет xauth , который создаст файл ~/.Xauthority y. Если все нормально, то файл уже создан и проверка показывает на наличие MAGIC COOKIE.
- Имеет смысл в качестве проверки иксов выполнить xclock прежде, чем запускать JAVA installer, или мастер настроек некоей корпоративной CRM, или ERP системы. Если показалось окно xclock, то соединение с X-сервером работает как надо.
Рис. 5 Собственно xclock, значит удаленные иксы настроены и работают.
- Если после логина по ssh была выполнена команда смены пользователя sudo su — для перехода в root, то тогда необходимо выставить переменную DISPLAY. Этого не надо делать, если используется изначальный пользователь и сеанс shell.
Я стараюсь по мере возможности тестировать сеанс Wayland при каждом новом релизе KDE Plasma, несмотря на многочисленные улучшения с каждым разом, на версии kde-apps-21.04.3 работать можно лишь на Plasma-X11. В чем бы не состояли преимущества Wayland, до тех пор пока в терминале зависает команда man, хаотично прыгают элементы ниспадающего меню и блуждает внешний монитор, старый и добрый X Window System остается вне конкуренции. Надеюсь так не будет продолжаться долго.
▍ Для дополнительной информации
- X Window system internals
- Can’t start X11 applications after su.
- Xterm cannot open display?
- Xlib — C Language X Interface
Источник: habr.com
Xorg, X11, Wayland? Серверы отображения Linux и протоколы с пояснениями
Вы когда-нибудь задавались вопросом, что именно делает X-сервер, Xorg, X11, Wayland и тому подобное?
Wayland или Xorg, что лучше? Это руководство для вас.
Вы всегда натыкаетесь на эти термины и знаете, что они имеют отношение к графике, но хотели бы узнать больше.
Что такое дисплейный сервер в Linux?
Сервер отображения — это программа, основной задачей которой является координация ввода и вывода данных от клиентов к остальной части операционной системы, оборудованию и друг другу. Дисплейный сервер взаимодействует со своими клиентами по протоколу дисплейного сервера.
Сервер отображения является ключевым компонентом любого графического интерфейса пользователя, в частности оконной системы. Это основной компонент графического интерфейса пользователя (GUI), который находится между графическим интерфейсом и ядром. Таким образом, благодаря дисплейному серверу вы можете использовать свой компьютер с графическим интерфейсом пользователя. Без него вы были бы ограничены только интерфейсом командной строки.
Очень важно не путать дисплейный сервер с окружением рабочего стола. Окружение рабочего стола (Gnome, KDE, Xfce, MATE и т.д.) использует дисплейный сервер.
Сервер отображения взаимодействует со своими клиентами по протоколу сервера отображения. В Linux существует три протокола сервера отображения. X11 и Wayland — два из них. Третий, Mir, выходит за рамки данного руководства.
X Window System, Xorg, X11, объяснение
X Window System, которую часто называют просто X, очень старая. Впервые появившись в 1984 году, она стала оконной системой по умолчанию для большинства UNIX-подобных операционных систем, включая Linux.
Сервер X.Org — это свободная реализация сервера отображения X Window System с открытым исходным кодом, управляемая фондом X.Org Foundation. Это приложение, которое взаимодействует с клиентскими приложениями по протоколу X11 для рисования объектов на дисплее и отправки событий ввода, таких как движения мыши, щелчки и нажатия клавиш. Обычно запускается X-сервер, который ожидает подключения к нему клиентских приложений. Xorg основан на модели клиент/сервер и поэтому позволяет клиентам работать как локально, так и удаленно на другой машине.
Если это не очевидно, то в дизайне X11 подразумевается, что приложение и дисплей не обязательно должны находиться на одном компьютере. Во времена разработки X было очень распространено, что X-сервер работал на рабочей станции, а пользователи запускали приложения на удаленном компьютере с большей вычислительной мощностью.
X11 — это сетевой протокол. Он описывает, как происходит обмен сообщениями между клиентом (приложением) и дисплеем (сервером). Эти сообщения обычно содержат примитивные команды рисования, такие как «нарисовать рамку», «написать этот символ в этой позиции», «левая кнопка мыши была нажата» и т.д.
Но X11 устарел, и он все еще был кучей хаков, сидящих поверх протокола, который не пересматривался более 30 лет. Большинство функций, которые предоставлял протокол X Server, больше не использовались. Практически вся работа, которую выполнял X11, была переложена на отдельные приложения и оконный менеджер. И все же все эти старые функции все еще существуют, отягощая все эти приложения, снижая производительность и безопасность.
Прочтите: Как установить Arch Linux: Пошаговое руководство по установке
Wayland, сервер отображения нового поколения
Wayland был начат Кристианом Хогсбергом, разработчиком X.Org, как личный проект в 2008 году. Это коммуникационный протокол, определяющий взаимодействие между сервером отображения и его клиентами. Wayland разрабатывается как бесплатный проект с открытым исходным кодом под руководством сообщества с целью замены X Window System (также известной как X11, или Xorg) современной, безопасной и более простой оконной системой.
В Wayland, compositor является сервером отображения. Compositor — это оконный менеджер, который предоставляет приложениям внеэкранный буфер для каждого окна. Менеджер окон объединяет буферы окон в изображение, представляющее экран, и записывает результат в память дисплея.
Протокол Wayland позволяет композитору отправлять входные события непосредственно клиентам, а клиенту — отправлять событие повреждения непосредственно композитору.
Как и в случае с X, когда клиент получает событие, он обновляет пользовательский интерфейс (UI) в ответ. Но в Wayland рендеринг происходит в клиенте, а клиент просто посылает запрос композитору, чтобы указать регион, который был обновлен.
Основное преимущество Wayland перед X заключается в том, что он начинает с нуля. Одной из основных причин сложности X является то, что с годами его роль менялась. В результате сегодня X11 выступает в основном как «действительно ужасный» протокол связи между клиентом и оконным менеджером.
Wayland также лучше, когда речь идет о безопасности. В X11 можно сделать то, что известно как «keylogging», позволяя любой программе существовать в фоновом режиме и читать, что происходит в других окнах, открытых в области X11. С Wayland этого просто не произойдет, поскольку каждая программа работает независимо.
Однако X Window System все еще имеет много преимуществ перед Wayland. Несмотря на то, что Wayland устраняет большинство недостатков дизайна Xorg, у нее есть свои проблемы. Несмотря на то, что проект Wayland существует уже более десяти лет, он не является на 100% стабильным. По состоянию на 2021 год, большинство видеоигр и графических приложений для Linux по-прежнему написаны для X11. Кроме того, многие графические драйверы с закрытым исходным кодом, например, для графических процессоров NVIDIA, еще не обеспечивают полной поддержки Wayland.
X не может существовать долго, и Wayland, во многих отношениях, является улучшением. Но на данный момент подавляющее большинство существующих приложений были написаны для Xorg. Пока все эти приложения не будут перенесены, Xorg необходимо поддерживать. Wayland пока не очень стабилен по сравнению с Xorg.
Но все же я уже как год использую wayland по-умолчанию в своей системе. А каким вы пользуетесь?
Источник: linuxcool.net
Графический интерфейс (X11)
Программный продукт , использующий X11, называется приложением ( application , другое значение – «применение»). Если считать, что сами графические возможности уже реализованы X-сервером и библиотеками, то программа и на самом деле окажется приложением к системе, и вся ее заслуга будет состоять в том, что она применила эти возможности для решения своей задачи.
Эмулятор терминала
С графикой или без, основным интерфейсом управления Linux была и остается командная строка. X11, предлагая иной способ взаимодействия с компьютером, не должна лишать пользователя возможности работать с самой системой испытанным и эффективным методом – через терминал. Поэтому первое совершенно необходимое X-приложение должно предоставлять возможность доступа к терминалу в X Window System .
Задача дать пользователю X11 командную строку решается довольно легко. Нужно завести X-приложение , окно которого работает аналогично
Рис. 16.5. Эмулятор терминала для X11 – xterm
окну терминала: передает символьную информацию от пользователя системе и обратно. Делается это уже описанным в лекции Mount-механизмом псевдотерминалов tty/pty (или pts/ptmx ): X-приложение получает во владение специальное устройство типа pty , связанное по вводу и выводу с терминальным устройством типа tty , с которым работает shell. Общее название таких программ – эмулятор терминала для X11 ( xterm ). Мефодий может запустить xterm все из той же виртуальной консоли , в которой определено значение переменной окружения DISPLAY, и получить доступ к командной строке уже из графической оболочки.
В левом верхнем углу открылось окно xterm , которое легло «поверх» открытого ранее xcalc . В открывшемся окне xterm Мефодий увидел привычное приглашение командной строки bash : теперь из этой командной строки можно выполнять любые команды, в том числе и запускать новые X-приложения , например, еще один xterm . Чтобы при этом избежать наложения окон друг на друга, можно запустить xterm с параметром «- geometry +150+150» , что заставит X-сервер выдать ему окно , верхний левый угол которого отстоит на 150 экранных точек (пикселей) от левой границы экрана , и на те же 150 – от верхней. В этом xterm значение DISPLAY унаследовано от родительского процесса и равно «:0» , так что окна всех запущенных из него X-приложений откроются на этом же экране .
Не следует путать программу xterm со способом организации рабочей станции (так называемый «X-терминал»): термины эти созвучны, но относятся к разным областям знаний. Нередко бывает, что на экране X-терминала (компьютера) есть окно терминала X11 (программы xterm ). XTerm передает сигналы как настоящий терминал, имеет богатый набор управляющих последовательностей (унаследованный от устройства «DEC VT102/VT220»), а вдобавок позволяет воспользоваться всеми преимуществами графической среды: выбрать шрифт, запомнить текст на экране (даже тот, который уже исчез с экрана ) и многое другое.
Кстати сказать, копирование текста при помощи мыши – свойство не только XTerm. На самом деле любое окно , зарегистрированное в X11 как текстовое, позволяет отметить (при постоянно нажатой первой кнопке или последовательными нажатиями третьей) часть текста. Выделенный текст можно немедленно вставить в любое окно текстового ввода нажатием второй кнопки. Утилита xcutsel предоставляет возможность работы с буфером обмена cutbuffer ), в котором текст может храниться сколь угодно долго.
Сеанс работы с X11
Как догадался Мефодий, команда startx делает несколько больше, чем просто запуск X-сервера ; она, помимо того, запускает несколько X-приложений . Для удобной работы в X11 пользователю прямо при запуске графической подсистемы потребуется сразу несколько приложений. Во-первых, нужно запустить приложение, которое позволит управлять окнами (как минимум перемещать их), чего не делает сам X-сервер , такие приложения называются диспетчерами окон и будут обсуждаться немного позднее. Кроме того, полезно сразу запустить разные мелкие программки, вроде индикатора загрузки системы xload или экранных часов xclock . Сам X-сервер не мешает настроить с помощью xset (можно поменять курсор, звуковой сигнал, переименовать кнопки мыши). Одним словом, пользователю, как правило, нужен небольшой стартовый сценарий, который запускался бы вместе с X-сервером .
С другой стороны, сервер хорошо бы останавливать, когда он больше не используется. Это, конечно, относится к схеме без диспетчера экрана ( xdm ): пользователь работает с терминала, потом запускает X-сервер для выполнения графических программ, выполняет их и останавливает сервер, чтобы графическим устройством мог воспользоваться кто-нибудь другой. Стандартный способ аварийного завершения работы XFree86 ( Ctrl+Alt+Backspace ), во-первых, доступен только на XFree86 , во-вторых, его можно отключить, а в-третьих, все запущенные приложения получат в этом случае сообщение о внезапной кончине сервера и тоже завершатся аварийно.
Если запускать не сам X-сервер , а некоторую оболочку вокруг него, называемую startx , то алгоритм работы будет такой. Сначала запустится X-сервер и сформируется значение переменной окружения DISPLAY . Затем запустится сценарий . xinitrc , находящийся в домашнем каталоге пользователя, а если такого нет – системный стартовый сценарий /usr/X11R6/lib/X11/xinit/xinitrc . Предполагается, что X-сервер будет работать до тех пор, пока выполняется .xinitrc . Когда все команды из .xinitrc отработают, его выполнение завершится, а вместе с ним завершится и работа сервера. Поэтому рекомендуется все X-приложения из .xinitrc , кроме последнего, запускать в фоне, чтобы командный интерпретатор не дожидался окончания их работы. В этом случае с завершением работы последнего приложения из .xinitrc завершится и сам X-сервер . Последней программой в стартовом сценарии может быть xterm , как это сделано в стандартном xinitrc , или диспетчер окон . Для завершения xterm (а с ним и всего сеанса работы X11) достаточно послать «^D» запущенному в нем shell, а окновод обычно имеет какую-нибудь кнопочку или менюшку «Exit». Программа, с завершением которой завершается сеанс X11, называется лидером сеанса (session leader ).
Лидер сеанса может быть указан и в качестве параметра startx в командной строке, например, по команде startx /usr/X11R6/bin/xterm будет открыт сеанс X11, лидером которого станет xterm – его окно откроется при запуске на экране X-сервера .
Диспетчер экрана организует сеанс работы с X11 сходным образом. Единственное отличие – в том, что ко времени запуска startx вручную пользователь уже имеет настроенное окружение (этим занимается стартовый командный интерпретатор ), а после регистрации в диспетчере экрана – нет. Поэтому стартовый сценарий нужно запускать другой – .xsession . На самом деле, и сам X-сервер необходимо перезапускать при использовании xdm . Несмотря на то, что пользователи взаимодействуют только с X-сервером , не используя виртуальные консоли , было бы неудобно и небезопасно сохранять какие бы то ни было настройки, сделанные одним пользователем, ко времени работы другого. Самое неприятное – это так называемый «клавиатурный вор» (keyboard grabber ), программа, притворяющаяся окноводом – для того лишь, чтобы запоминать все, что пользователь ввел с клавиатуры (злоумышленников интересуют, как правило, пароли).
Нарушения безопасности легко избежать, если не использовать xhost (авторизацию на основе адреса ) и не доверять X-серверу , запущенному не при вас. Можно доверять автоматически запускаемой в сеансе программе xauth , которая связывается с X-сервером и записывает в файл ~/.Xauthority специальный ключ доступа. Все X-приложения пользуются библиотекой libX11 , которая обязательно обращается к этому файлу. Таким образом, X-приложение может воспользоваться X-сервером , если оно знает его адрес (указанный в переменной окружения DISPLAY или переданный ключом -display ) и авторизовано сервером (по адресу компьютера или по ключу доступа в ~/.Xauthority ).
Ресурсы X11
X-приложения создаются с помощью разнообразных готовых инструментариев. Большая их часть разрабатывается независимыми авторами по всему миру (это общее свойство свободного ПО, см. лекцию 18), но библиотека самого низкого уровня, «X Lib», и несколько более высокоуровневых библиотек с давних пор включаются в основной дистрибутив X11. Из них наиболее примечательна «X Toolkit» (Xt), организующая из стандартных окон X11 оконные примитивы ( widgets ).
Дело в том, что каждый объект X11 обладает некоторым набором свойств, вроде размера окна , цвета фона или текстового содержимого. Для удобства доступа примитивы Xt, реализованные поверх объектов Xlib, имеют собственные имена (у каждого объекта – свое) и фамилии (одинаковые у всех объектов одного класса).
Более того, программа, написанная на Xt, имеет карту объектов, в которой указано, какой объект внутри какого находится, и приведены имена объектов и их классов. Посмотреть структуру запущенного X-приложения можно с помощью программы editres ( «Commands/Get Tree» ). Например, программа xlogo состоит из трех примитивов: xlogo (класс XLogo) и вложенных в него xlogo.xlogo (класс Logo) и shellext (неоконный, класс VendorShellExt). Мало того, свойства этих примитивов можно подменить прямо в работающей программе. Можно, например, на время работы перекрасить фон xlogo в красный цвет.
Xlib, со своей стороны, предоставляет универсальный способ хранить такие настройки в файле. Многие приложения хранят свои настройки по умолчанию в /usr/X11R6/lib/X11/app-defaults/ ИмяКласса (в некоторых системах этот каталог перенесен, как ему и подобает, в /etc/X11 ). ИмяКласса – это имя класса самого главного окна этого приложения. Пользователь может дополнить настройки ресурсов, которые сервер накапливает при старте, при помощи команды xrdb -merge файл_настроек или переписать их заново (ключ «-load» ). Приложению остается только вызвать специальную функцию Xlib, которая считывает настройку с определенным именем из таблиц сервера. Если xrdb не запускалась ни разу (в том числе и в стартовом сценарии), запрос приложения будет направлен не в таблицу сервера, а непосредственно в файл ресурсов .Xdefaults 6 Кроме этого файла в домашнем каталоге пользователя можно обнаружить файл .Xresources , очень похожий по функции и аналогичный по синтаксису. Разница между этими файлами в использовании: .Xresources загружается только в процессе исполнения xinitrc при помощи утилиты xrdb , а .Xdefaults в дополнение к этому читается автоматически средствами libX11 . , лежащий в домашнем каталоге. В этом случае для изменения настроек не надо запускать xrdb .
Xt добавляет в эту процедуру иерархию ресурсов. Как это можно наблюдать в editres , при задании свойства ресурса используются четыре конструкции: имя ресурса, имя класса, разделитель «.» , означающий, что один ресурс непосредственно вложен в другой и разделитель «*» , означающий, что ресурс в конце концов вложен в другой (возможно, по цепочке). Например, для задания цвета фона в программе xload можно использовать именование xload.paned.load.background (это все по именам). Можно попробовать единым махом изменить цвет фона всех примитивов этой программы, записав в .Xdefaults (или передав xrdb ) строку вида «XLoad*background: midnightblue» .
Если в .Xdefaults есть несколько строк, удовлетворяющих имени ресурса, то имена собственные имеют преимущество над классами, а «.» – над «*» . Так что запись вида «*Text*background: peachpuff» повлияет только на те примитивы класса Text и вложенные в них, для которых нет более строгого указания (например, «*Text.background» или «XConsole*Text*background» ). Обратите внимание, как поэтично называются порой цвета в X11! Посмотреть таблицу цветов можно командой xlscolors .
К сожалению, Xt – все-таки довольно старая библиотека, не во всем следующая новым веяниям в области графического интерфейса. Для быстрой разработки оконных программ нужны разнообразные и мощные инструменты, которые манипулируют понятиями, далеко ушедшими от стандартного «окно–меню–кнопка». Если такие инструментарии написаны с применением Xt (например, Xm, open Motif , Xaw, Athena Widget), их настройки можно поселить в .Xdefaults . Проблема еще и в том, что структуру классов Xt неудобно использовать при программировании на языке C++, а именно на нем сейчас пишется большинство оконных приложений. Так что самые мощные инструментарии для X11 – Qt («The Q Toolkit») и GTK («The GIMP Toolkit») – не используют App-defaults.
Источник: intuit.ru