Есть два (*) метода, которые я могу придумать.
/ etc / sudoers.d
Добавьте этот один сценарий, вызов ../p_root
, чтобы получить конфигурацию sudo без пароля в каталоге sudoers.d
. Эта конфигурация позволит only ../p_root
вызываться с паролем sudo. Крайне важно, чтобы вы заблокировали права на запись скрипта. По крайней мере, удалите разрешение других на запись chmod o-w ../p_root
. В противном случае кто-то может воспользоваться этим и запустить произвольный код как root
, отредактировав файл и добавив свой собственный контент.
Каждый файл в /etc/sudoers.d
содержит правила для sudo
. Вы можете добавить свои собственные файлы в этот каталог, чтобы разумно управлять вашей системой. Файлы в /etc/sudoers.d
читаются по порядку (условно называть их 10-something
, 20-else
, et c). Они должны быть отредактированы с помощью visudo
.
visudo /etc/sudoers.d/20-special-proot
Пример содержимого (полный путь к исполняемому файлу обязателен)
youruser ALL=(ALL) NOPASSWD: /usr/bin/bash /full/path/to/p_root
Подробнее о sudo
SetUID
Второй - настройка SetUID. Это разрешение файла, которое позволяет выполнять сценарий с разрешения его владельца. т. е. это означает, что вы владеете сценарием ../p_root
для root
, и тот, кто может его выполнить (группа / другие), всегда будет запускать сценарий как root
.
chown root.yourgroup
chmod u+s ../p_root
chmod o-w ../p_root
Опять тот же уровень безопасности последствия применяются здесь. Тот, кто может выполнить этот файл (особенно группа или другие имеют разрешения на выполнение), будет запускать все как root
. Если пользователь с низкими привилегиями (например, другие) имеет права на запись, он может просто отредактировать файл, добавить себя в root
и изменить PS1
на черный на черном.
Подробнее
sudo (*)
По совету lior.i я добавляю эту опцию, тоже.
Вы можете добавить префикс sudo
и bash
к пути вашего скрипта как выполненную команду для достижения той же цели.
Popen(['sudo', 'bash', '/path/to/script'])
Попен заслуживает изучения и рекомендуемого способа выполнения подпроцессов, особенно в долгосрочной перспективе. Другими словами, он может делать все остальное. Я обнаружил, что одной из причин этого является гибкость и отладка. Гибкость, чтобы полностью отделить подпроцесс от его родителя или нет. По умолчанию, если родитель убит изящно (SIGINT / Ctrl + C), дочерний элемент также получит сигнал d ie. Точно так же они также прикреплены в своих файловых дескрипторах stdin
, stdout
и stderr
. Возможно, вы захотите использовать новый файловый дескриптор для какой-то хитрой волхвы c.
Внимание, которое вы должны принять, если вы не используете его в производстве. Оставление аппликативного пользователя без пароля sudo представляет собой угрозу безопасности, аналогичную простому запуску всего как root.