Почему sudo изменяет идентификатор сеанса процесса, используя setsid()?

На чтение 3 мин Опубликовано 04.01.2025

Вопрос или проблема

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

Как и предполагалось, strace показывает, что sudo вызывает setsid после clone, что означает, что мои (python) сценарии находятся в другой группе процессов и не получают те же сигналы, что и процесс sudo.

Какова могла быть причина вызова sudo функции setsid? Есть ли в этом польза для безопасности? Почему нет эквивалента опции su --session-command для отключения такого поведения (что также не рекомендуется, согласно man page)?

Ответ или решение

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

Причины использования setsid() в sudo:

Изоляция процесса: setsid() создает новую сессию и делает вызываемый процесс лидером этой сессии. Это предотвращает воздействие терминала, используемого исходным процессом, на новый процесс, и обеспечивает их независимость. В результате скрипт, выполняемый через sudo, не будет получать несанкционированные сигналы, такие как SIGINT, если это не требуется.
Безопасность: Изоляция процессов уменьшает риск, связанный с несанкционированным доступом или вмешательством в выполнение кода. Она помогает предотвратить ситуации, в которых пользователь или процесс, работающий в одной сессии, может непреднамеренно или злонамеренно прервать или изменить выполнение команды.
Контроль над средой выполнения: Создание новой сессии позволяет лучше управлять средой выполнения, включая переменные окружения и другие параметры системы, обеспечивая корректность и предсказуемость выполнения команд.

Почему может отсутствовать возможность отключить setsid() в sudo:

Комплексность исполнения: Если бы sudo предлагало опцию для отключения setsid(), это могло бы привести к повышению сложности при управлении и отладке процессов, так как их поведение могло бы значительно различаться в зависимости от конфигурации.
Риски безопасности: Разрешение выполнения команд без изоляции процессов увеличивает поверхность атаки и может привести к уязвимостям, которые могут быть использованы злоумышленниками.

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

Таким образом, использование setsid() в sudo обеспечивает баланс между безопасностью и функциональностью, при этом сохраняя возможность выполнения сложных операций от имени других пользователей с минимальными рисками.