Я должен использовать 'sudo' или 'su' в сценарии запуска?
Существует резервный модуль политики, который может использоваться, который обеспечивает backup_t и позволяет системные резервные копии. Его часть tresys refpolicy, http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/src/selinux-policy-clip/policy/modules/admin/backup.te
После установки, просто устанавливает контекст файла резервного сценария к backup_exec_t, и это сможет получить доступ к целой системе.
Если можно легко изменить программу так, чтобы она отбросила свои полномочия, то это - лучший подход. Переключение идентификатора пользователя в сценариях запуска является kludgey и довольно негибкий, даже если это действительно "работает".
-
1я закончил тем, что делал это. Я полагал, что могу использовать os.setuid, который является намного более чистым решением, чем использование sudo или su. – Waleed Hamra 20.02.2013, 14:13
Из этих двух я использовал бы su с этой целью, потому что это менее настраивается и поэтому более предсказуемо. Если Вы используете sudo в Вашем init сценарии, и затем (случайно или целеустремленно) удаляют root ALL=(ALL) ALL запись в /etc/sudoers, Ваш init сценарий загадочно повредится.
Кроме того, я использовал бы следующую форму для сокращения места конфигурации еще больше:
su -s /bin/sh -c "my_program my_args etc" my_user
-s опция означает, что можно изменить оболочку пользователя по умолчанию на/bin/false или/sbin/nologin или что-то, не повреждая сценарий. Вы могли бы также хотеть перенаправить стандартный ввод-вывод к /dev/null или некоторое другое подходящее место, если Ваша программа уже не обрабатывает это само.
С точки зрения удобства я предлагаю, чтобы Вы посмотрели на chpst программу от runit стопки супервизора. Это очень удобно и сохраняет один от питания с параметром командной строки, выходящим и т.д., который является болью с sudo/su.
Если Вы хотите запустить программу как другой пользователь, Вы называете ее точно так же, как это:
chpst -u my_user /path/to/program
Это делает setsid, setgid, execve на Вашей программе это - все (она имеет много других хороших функций).
Если Ваше распределение включает busybox, также можно проверить, имеет ли это chpst апплет скомпилировал, Вы можете уже иметь его и не должны разделять пакет.
-
1
chpstнаборы только uid угловой ценуроз и в конечном счете переменные среды для UID и GID. Это не настроит целую среду оболочки для Вас как ожидалось (например, $HOME...). – Robert Zaremba 15.05.2017, 14:31
Технически, оба должны хорошо работать, однако Вы, вероятно, хотите следовать конвенции здесь. Sudo обычно используется для подъема для укоренения для выполнения единственной команды, в то время как su обычно используется для изменения на нового пользователя и затем команды выполнения как тот новый пользователь:
Тем не менее существует несколько представлений о sudo по сравнению с su, если Вы делаете быстрый поиск Google:
-
1На самом деле
suобычно используется для становления другим пользователем в то время какsudoиспользуется для выполнения специальных команд как другой пользователь.su -c(грубый) эквивалентsudoиsudo -sэквивалентsu. Вопреки широко распространенному мнению "su" в любой команде поддерживает "пользователя переключателя" не "суперпользователь". Они оба для переключения на любого пользователя, но обоих значений по умолчанию для укоренения. – bahamat 20.02.2013, 01:00 -
2. Я просто заявлял, что я видел используемый в качестве конвенции по большей части Linux/Unix в прошлом; sudo обычно для единственной основанной на корне команды, в то время как su в более общем плане для выполнения как другой пользователь. – sbtkd85 20.02.2013, 17:15
-
3Sudo может повредить init сценарии если
requirettyвключен в/etc/sudoers (на по умолчанию в 6 центах, 7 центах, мягкой фетровой шляпе) github.com/influxdb/influxdb/issues/800 – spuder 10.10.2014, 19:38