удаление сокета
исходник посмотри того места, где сокет создают, в других местах ведь не удаляется ничего лишнего, похтому наверняка там что-то криво пропатчили
другая программа стереть конечно сможет, если захочет, но хотеть-то как раз никто и не должен
всякие syscall tracker - это патчи к ядру, геморно их ставить
другая программа стереть конечно сможет, если захочет, но хотеть-то как раз никто и не должен
всякие syscall tracker - это патчи к ядру, геморно их ставить
Проблема разрешилась. На всякий случай, рассказываю.
Поставил syscalltracker. Заставил его логгить все unlink. Выяснилось, что сокет стирает сам XFree86. Дальнейшее ковыряние показало, что второй пользователь запускает X не с помощью команды startx -- :1, а с помощью startx -- :a. Почему ему такое в голову взбрело - не знаю. При этом происходит следующее (опять sct): при запуске X-сервер проверяет нет ли его уже такого, смотря файлы типа /tmp/.Xa-lock, их нету - он считает, что X-серверов на этом дисплее нет. После чего он парсит параметры, не может найти дисплей :a, ставит дефолтный :0. Однако на :0 сервер уже есть. Второй придерживается другого мнения - и грубо рубит ему авторизацию, сносит его сокет, делает новый и так далее. В результате второму удается запустить и работать на этом дисплее. Первому серверу от таких манипуляций становится плохо - он начинает сходить с ума.
Сделал так: похачил скрипт startx чтобы он парсил параметры более аккуратно, если они не нравятся - грязно ругался.
Непонятно только, считать это багом X-сервера или нет? С одной стороны, конечно, это идиотизм юзера, нефиг такие параметры бредовые указывать. Но с другой стороны - один пользователь может сильно запортить X другого, что нехорошо.
Поставил syscalltracker. Заставил его логгить все unlink. Выяснилось, что сокет стирает сам XFree86. Дальнейшее ковыряние показало, что второй пользователь запускает X не с помощью команды startx -- :1, а с помощью startx -- :a. Почему ему такое в голову взбрело - не знаю. При этом происходит следующее (опять sct): при запуске X-сервер проверяет нет ли его уже такого, смотря файлы типа /tmp/.Xa-lock, их нету - он считает, что X-серверов на этом дисплее нет. После чего он парсит параметры, не может найти дисплей :a, ставит дефолтный :0. Однако на :0 сервер уже есть. Второй придерживается другого мнения - и грубо рубит ему авторизацию, сносит его сокет, делает новый и так далее. В результате второму удается запустить и работать на этом дисплее. Первому серверу от таких манипуляций становится плохо - он начинает сходить с ума.
Сделал так: похачил скрипт startx чтобы он парсил параметры более аккуратно, если они не нравятся - грязно ругался.
Непонятно только, считать это багом X-сервера или нет? С одной стороны, конечно, это идиотизм юзера, нефиг такие параметры бредовые указывать. Но с другой стороны - один пользователь может сильно запортить X другого, что нехорошо.
> считать это багом X-сервера или нет?
считать
считать
скорее багом startx
А вот под FreeBSD такой DoS уже давно не работает:
В /etc/rc:
В /etc/rc:
rm -f /tmp/.X*-lock
rm -fr /tmp/.X11-unix
mkdir -m 1777 /tmp/.X11-unix
ещё нужно, чтобы сервер не от рута работал
Под FreeBSD реализована защита не от глючного startx, а от злоумышленника, который может стереть любой сокет.
P.S. Не от рута иксы вроде бы умеют работать под OpenBSD.
P.S. Не от рута иксы вроде бы умеют работать под OpenBSD.
> не от глючного startx
startx и xinit передают аргументы после "--" серверу без изменений AFAIK, так что глюк именно в сервере.
> а от злоумышленника, который может стереть любой сокет
это понятно
открою ещё секрет: 1777 бывает не только в FreeBSD
> Не от рута иксы вроде бы умеют работать под OpenBSD
X - это небезопасно, странно что в OpenBSD вообще есть такое
толку-то? всё равно прямой доступ к железу нужен
startx и xinit передают аргументы после "--" серверу без изменений AFAIK, так что глюк именно в сервере.
> а от злоумышленника, который может стереть любой сокет
это понятно
открою ещё секрет: 1777 бывает не только в FreeBSD
> Не от рута иксы вроде бы умеют работать под OpenBSD
X - это небезопасно, странно что в OpenBSD вообще есть такое
толку-то? всё равно прямой доступ к железу нужен
Только почему-то сами XFree это игнорируют, да и разработчики другие ОС, с которыми поставляется Х, тоже.
> а от злоумышленника, который может стереть любой сокет
это понятно
открою ещё секрет: 1777 бывает не только в FreeBSD
X - это небезопасно, странно что в OpenBSD вообще есть такое
толку-то? всё равно прямой доступ к железу нужен
Там для этого создается специальный девайс. Соответсвенно к XFree присобачен не хилый хак, который заставляет его
через этот девайс работать. Прямой доступ к железу конечно дается, но на безопасность системы это не влияет. Во всяком
случае очередное переполнение в xlib не опасно.
Оставить комментарий
Landstreicher
Я уже писал про проблему с запуском второго X-сервера. Сейчас вдруг внезапно обнаружил, что в каталоге /tmp/.X11-unix при это исчезает сокет X0, на котором слушает сервер. Понятно что при этом все перестает работать. Вопрос: кто может стирать сокет и почему?1) Можно ли как-то стирать сокет, кроме как unlink?
2) Как это можно отловить? Пускать X-сервер под gdb - как-то совсем жестоко.
3) Может ли этот сокет стереть какая-то другая программа (window manager, session manager). Программ много - за всеми не уследишь.
4) Возникла такая мысль. Слышал что есть какой-то syscall tracker, который позволяет логгить системные вызовы. Можно ли в таком случае поставить его логгить вызовы типа unlink, чтобы посмотреть какой процесс его трет?
5) У кого еще какие идеи есть?