Открыть список
Как стать автором
Обновить

Комментарии 11

1. В современных операционных системах с systemd, в которых дампы обрабатывает systemd-coredump, они сохраняются доступными только на чтение от root, а пользователь не может их прочитать.
2. Во многих ОС по умолчанию процессы одного пользователя могут читать память (через /proc/PID/mem) других процессов и отлаживать их (через ptrace).
Уверен, не то, что вы ожидали.

Наверное потому, что документацию надо все-таки почитать?

но она по-прежнему мрачна.

Я не понимаю вашего драматизма. Сигналы это асинхронное межпроцесное взаимодействие. Права доступа соблюдены. Безопасность в данном случае соблюдается также, как и для других вещей.
Если юзер не может своим процессам ничего послать и управлять, то как например написать управляющий менеджер для своего демона? Как управлять процессами в бэкграунде? Как вообще отлаживать, мониторить, смотреть список и информацию?
Сигналы — крайне удобная вещь, и во всем что вы написали нужно было добавлять не драматизм, а просто дочитать документацию и пользоваться.
Что мне кажется нехорошим в сигналах, так это как они работают по умолчанию. Если какие-то сигналы приложению не нужны, оно должно явно сказать об этом. Если не скажет, то оно будет обрабатывать их не самым очевидным образом. Мне кажется, почти все сигналы по умолчанию было бы очевиднее всего игнорировать, а не падать в корку.
с какой стати все сигналы вызывают падение с кордампом?
Есть конкретные сигналы — sigterm, sighup, suspend и множество других — их НЕОБХОДИМО обрабатывать соответственно, если мы работаем в posix — этого поведения ожидает и операционная система и пользователь и администратор.
Вот написал ты программу консольную. Запустил и потом она тебе не нужна, ты жмешь Ctrl-C, а она не прерывается — ты ж СПЕЦИАЛЬНО не указал какими кнопками надо прерывать. Или под винду программу написал простенькую, а у нее крестик не работает, ты ж СПЕЦИАЛЬНО не указал.
Или твоя программа полезла в чужую память, ядро ей кидает segmentation fault, а программа не падает а лезеть в память и ломает все процессы, ТЫ Ж СПЕЦИАЛЬНО НЕ УКАЗАЛ, что надо обрабатывать такие сигналы?

В общем работа сигналов по умолчанию — это хорошо. Про сигналы следует почитать, и понимать что все необходимые сигналы — приложению нужны. Необязательные и так игнорируются (usr1, usr2), а скрывать лень чтения документации по базовым вещам не стоит скрывать за «неочевидностью»

В Линуксе разделение прав делается через пользователей. Если программы запущены под одним пользователем, то они могут делать друг с другом что угодно, например, лезть в память друг другу напрямую, без всяких сигналов, читать файлы друг друга итд.


Чтобы защитить программу от воздействия других программ, ее следует запускать из-под отдельного пользователя, как например сделано в Андроиде, где каждое приложение работает под отдельным UID.


Вы мануал по ptrace или по /proc/self/mem почитайте, вас ждут новые открытия.


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

Сигналы сигнализируют об ошибках вроде обращения по недействительному адресу или выполнения несуществующей инструкции процессора. Дамп в таком случае позволяет программисту найти причину ошибки.

Более корректный, но менее драматичный заголовок — 'Как *nix-сигналы позволяют читать память других процессов, выполняемых под вашим пользователем'. Автор, не обижайтесь, но вы или ничего не поняли про систему разграничения привилегий в никсах, или сознательно хайпите на неправде, что грешновато.

В Ъ systemd системах достаточно либо сконфигурить systemd-coredump на запрет сохранения корьдампов, либо раздать права 700 на папку /var/lib/systemd/coredump или на системный журнал с корьдампами, если в качестве хранилища указан journal. Ессесно journald, в этом случае, тоже должен быть правильно сконфигурирован и/или отредактирован штатный systemd-coredump@.service дабы корки валились в отдельный journald namespace, если доступ к системному журналу нужен непривилегированному пользователю. Короче, КМК, в этом посте прослеживается банальное незнание матчасти. ;-)
Умные люди об этом давно уже подумали и написали такую отличную штуку как SELinux, с помощью которого можно ограничить процессы на уровне системных вызовов. В RHEL-подобных дистрибутивах он включен по умолчанию. Если вы беспокоитесь, кто кому какие сигналы шлет и какие файлы читает, то SELinux определенно ваш выбор.
Я написал простую программу с таким обработчиком сигнала 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

Ну и грамотная раздача прав на хранилище и/или чтение журналов кем ни попадя спасут «отца русской демократии» ©
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.