Комментарии 11
2. Во многих ОС по умолчанию процессы одного пользователя могут читать память (через /proc/PID/mem) других процессов и отлаживать их (через ptrace).
Уверен, не то, что вы ожидали.
Наверное потому, что документацию надо все-таки почитать?
но она по-прежнему мрачна.
Я не понимаю вашего драматизма. Сигналы это асинхронное межпроцесное взаимодействие. Права доступа соблюдены. Безопасность в данном случае соблюдается также, как и для других вещей.
Если юзер не может своим процессам ничего послать и управлять, то как например написать управляющий менеджер для своего демона? Как управлять процессами в бэкграунде? Как вообще отлаживать, мониторить, смотреть список и информацию?
Сигналы — крайне удобная вещь, и во всем что вы написали нужно было добавлять не драматизм, а просто дочитать документацию и пользоваться.
Есть конкретные сигналы — sigterm, sighup, suspend и множество других — их НЕОБХОДИМО обрабатывать соответственно, если мы работаем в posix — этого поведения ожидает и операционная система и пользователь и администратор.
Вот написал ты программу консольную. Запустил и потом она тебе не нужна, ты жмешь Ctrl-C, а она не прерывается — ты ж СПЕЦИАЛЬНО не указал какими кнопками надо прерывать. Или под винду программу написал простенькую, а у нее крестик не работает, ты ж СПЕЦИАЛЬНО не указал.
Или твоя программа полезла в чужую память, ядро ей кидает segmentation fault, а программа не падает а лезеть в память и ломает все процессы, ТЫ Ж СПЕЦИАЛЬНО НЕ УКАЗАЛ, что надо обрабатывать такие сигналы?
В общем работа сигналов по умолчанию — это хорошо. Про сигналы следует почитать, и понимать что все необходимые сигналы — приложению нужны. Необязательные и так игнорируются (usr1, usr2), а скрывать лень чтения документации по базовым вещам не стоит скрывать за «неочевидностью»
В Линуксе разделение прав делается через пользователей. Если программы запущены под одним пользователем, то они могут делать друг с другом что угодно, например, лезть в память друг другу напрямую, без всяких сигналов, читать файлы друг друга итд.
Чтобы защитить программу от воздействия других программ, ее следует запускать из-под отдельного пользователя, как например сделано в Андроиде, где каждое приложение работает под отдельным UID.
Вы мануал по ptrace или по /proc/self/mem почитайте, вас ждут новые открытия.
Мне кажется, почти все сигналы по умолчанию было бы очевиднее всего игнорировать, а не падать в корку.
Сигналы сигнализируют об ошибках вроде обращения по недействительному адресу или выполнения несуществующей инструкции процессора. Дамп в таком случае позволяет программисту найти причину ошибки.
Более корректный, но менее драматичный заголовок — 'Как *nix-сигналы позволяют читать память других процессов, выполняемых под вашим пользователем'. Автор, не обижайтесь, но вы или ничего не поняли про систему разграничения привилегий в никсах, или сознательно хайпите на неправде, что грешновато.
Я написал простую программу с таким обработчиком сигнала SIGUSR1: напечатать на экран строку «1», войти в бесконечный цикл. Я надеялся, что если много раз посылать этой программе сигнал SIGUSR1, то обработчик будет вызываться многократно
Очень много ваших открытий описаны уже вот здесь man7.org/linux/man-pages/man7/signal.7.html
Вот, например
Queueing and delivery semantics for standard signals
If multiple standard signals are pending for a process, the order in
which the signals are delivered is unspecified.
Standard signals do not queue. If multiple instances of a standard
signal are generated while that signal is blocked, then only one
instance of the signal is marked as pending (and the signal will be
delivered just once when it is unblocked). In the case where a
standard signal is already pending, the siginfo_t structure (see
sigaction(2)) associated with that signal is not overwritten on
arrival of subsequent instances of the same signal. Thus, the
process will receive the information associated with the first
instance of the signal.
Там же есть о том, на каком стеке может выполняться обработчик. Как процессы могут реагировать на сигнал и т.д… Очень советую к прочтению.
Ух. Есть старинный текст о сигналах, который начинается так:
"Если судить по исходникам популярных программ и обсуждениям Usenet
за последние лет 20, то обработка сигналов Unix — это игра, в
которой большинство участвует, так и не удосужившись выучить правила.
Программисты привыкли, что если код не засбоит хотя бы один раз,
то он будет работать во всех случаях"
https://www.opennet.ru/base/dev/unix_signals.txt.html
man systemd-coredump
man coredump.conf
man coredumpctl
Ну и грамотная раздача прав на хранилище и/или чтение журналов кем ни попадя спасут «отца русской демократии» ©
Как *nix-сигналы позволяют читать память других процессов