Linux запустить службу от другого пользователя

Как заставить мою службу systemd запускаться через определенного пользователя и запускать при загрузке?

Я только что обновился с сервера Ubuntu 14 до версии 15. У меня возникли проблемы с запуском скрипта выскочки после обновления и прочитал, что systemd является новым значением по умолчанию. Я далек от эксперта по Linux, поэтому, пожалуйста, пройдите на меня: -)

Вот что мой скрипт upstart был раньше:

Основываясь на выскочке на страницу systemd wiki , я использовал таблицы, представленные там, чтобы сопоставлять вещи так близко, как я мог в моем новый системный файл systemd:

Этот файл находится в /home/robert/.config/systemd/user/nzbget.service . Чтобы запустить службу вручную, я выполнял:

Это отлично работает. Однако, когда я выхожу из сеанса SSH, служба отключается. Кроме того, он не запускается при загрузке или входе в систему. Я хочу, чтобы он вел себя так же, как и в качестве услуги upstart: я хочу, чтобы он запускался при загрузке, запускался постоянно и как конкретный пользователь.

Что мне нужно сделать, чтобы получить эту конфигурацию?

2 ответа

Первая проблема

Вы можете указать директивы User= и Group= в разделе [Service] файла устройства.

Вторая проблема

Чтобы запустить службу при загрузке, вы не должны помещать ее в свою домашнюю папку. Вместо этого поставьте его под /etc/systemd/system/ . Это папка, предназначенная для использования системным администратором (т. Е. Вы) для добавления новых общесистемных служб.

• /usr/lib/systemd/system/ предназначен для пакетов, которые хотят установить единичные файлы, хотя в Debian и Ubuntu на самом деле папка /lib/systemd/system/ потому что различные папки bin и lib еще не объединены в унифицированный префикс /usr/ .
• /usr/local/systemd/system/ предназначен для установки модулей локально скомпилированными пакетами.

Тестирование устройства

После того, как файл устройства находится в соответствующем месте, вы можете попробовать запустить устройство немедленно, набрав systemctl start , как обычно. Он должен работать без ввода полного пути устройства. Расширение также не нужно указывать, если это .service .

Включение устройства

Прежде чем вы сможете включить свой блок, вам нужно добавить раздел [Install] , под которым вы должны добавить директиву WantedBy=multi-user.target . Эта директива определяет этап процесса загрузки, во время которого должна запускаться служба (если она была включена). multi-user.target подходит для большинства служб.

После того, как эта информация будет добавлена, вы можете использовать systemctl enable , который позволяет устройству, что делает systemd с этого момента автоматически запускать его во время загрузки на указанном этапе.

Вам может быть интересно использовать функциональные возможности systemd для пользователя. Он включен с помощью loginctl enable-linger USERNAME .

Он вызывает отдельный диспетчер служб для соответствующего пользователя, который запускается при загрузке, поэтому ваши пользовательские единицы в

/.config/systemd/user будут отобраны и обработаны при загрузке и завершении работы в зависимости от конфигурации вашего сервиса.

Вы также можете использовать systemctl —user для управления и настройки служб (сервисов), которые будут работать в диспетчере служб вашего пользователя, а не в системе.

Источник

Рекомендуется запускать службу Linux от имени другого пользователя

службы по умолчанию запускаются как root во время загрузки на моем поле RHEL. Если я правильно помню, то же самое верно и для других дистрибутивов Linux, которые используют сценарии инициализации в /etc/init.d .

как вы думаете, это лучший способ вместо того, чтобы процессы запускались как (статический) пользователь по моему выбору?

единственный метод, к которому я пришел, был использовать что-то вроде:

но это кажется немного неопрятным.

есть ли немного магии спрятан это обеспечивает простой механизм для автоматического запуска служб в качестве других, некорневых пользователей?

EDIT: я должен был сказать, что процессы, которые я запускаю в этом случае, являются либо скриптами Python, либо программами Java. Я бы предпочел не писать родную обертку вокруг них, поэтому, к сожалению, я не могу позвонить setuid () как предлагает черный.

8 ответов:

в Debian мы используем start-stop-daemon утилита, которая обрабатывает pid-файлы, изменяя пользователя, помещая демона в фоновый режим и многое другое.

Я не знаком с RedHat, но daemon утилита, которую вы уже используете (которая определена в /etc/init.d/functions , кстати.) упоминается везде как эквивалент start-stop-daemon , поэтому либо он также может изменить uid вашей программы, либо способ, которым вы это делаете, уже правильный.

если вы посмотрите по сети, есть несколько готовых оберток, которые можно использовать. Некоторые из них даже могут быть уже упакованы в RedHat. Взгляните на daemonize , например.

рассмотрев все предложения здесь, я обнаружил несколько вещей, которые, я надеюсь, будут полезны другим в моем положении:

хоп прямо в точку меня в /etc/init.d/functions : в

• некоторые демоны (например, apache) делают это сами по себе, вызывая setuid ()
• вы могли бы использовать права доступа к файлу-файл флаг для запуска процесса от имени другого пользователя.
• конечно, решение, которое вы упомянули, также работает.

если вы собираетесь написать свой собственный демон, то я рекомендую вызвать setuid(). Таким образом, ваш процесс может

1. использовать суперпользователя (например, открытые файлы, создать PID-файлы).
2. отбросьте свои привилегии root в определенный момент во время запуска.

просто добавить некоторые другие вещи, чтобы следить за:

• Sudo в init.D скрипт не годится, так как ему нужен tty («sudo: извините, у вас должен быть tty для запуска sudo»)
• Если вы демонизируете приложение java, вы можете рассмотреть Java Service Wrapper (который предоставляет механизм для установки идентификатора пользователя)
• Другой альтернативой может быть su — session-command=[cmd] [user]

на виртуальной машине CENTOS (Red Hat) для сервера svn: отредактировано /etc/init.d/svnserver чтобы изменить pid на что-то, что svn может написать:

оригинальный pidfile был /var/run/svnserve.pid . Демон не запустился, потому что только root мог писать там.

некоторые вещи, чтобы наблюдать за:

• как вы упомянули, su запросит пароль, если вы уже являетесь целевым пользователем
• аналогично, setuid (2) завершится неудачей, если вы уже являетесь целевым пользователем (на некоторых ОС)
• setuid (2) не устанавливает привилегии или элементы управления ресурсами, определенные в /etc/limits.conf (Linux) или /etc/user_attr (Solaris)
• Если вы идете по маршруту setgid(2)/setuid(2), Не забудьте вызвать initgroups (3) — Подробнее об этом здесь

обычно я использую /sbin/su для переключения на соответствующего пользователя перед запуском демонов.

почему бы не попробовать следующее в скрипт:

это сработало для меня.

Мне нужно было запустить пружину .jar приложение в качестве службы, и нашел простой способ запустить это как конкретный пользователь:

Я изменил владельца и группу моего файла jar на пользователя, которого я хотел запустить. Затем симулировал эту банку в init.D и начал службу.

Источник

linux-notes.org

Запустить команду от другого пользователя в Unix/Linux

Иногда, просто необходимо запустить команду от другого пользователя. И существует несколько способов, как это можно сделать. Я расскажу о них в своей статья «Запустить команду от другого пользователя в Unix/Linux».

Запустить команду от другого пользователя в Unix/Linux — способ 1

И так, можно использовать утилиту SUDO. Рассмотрим пример:

• -H YOUR_HOME: Задает HOME (Переменное окружение для хома конкретного юзера) и по умолчанию — это root.
• -u YOUR_USER: Задаем пользователя от которого будет выполнена команда.
• -c YOUR_COMMAND: Служит опцией для ввода команды.

Запустить команду от другого пользователя в Unix/Linux — способ 2

Можно использовать утилиту SU. И сейчас приведу несколько примеров.

Логин в root юзера

Чтобы получить рута, выполните:

Запустить команду как root юзер

Вот пример команды:

Выполнить команду от другого пользователя с помощью su

И так, вот пример:

Рассмотрим другой пример:

• — — Будет имитировать логин указанного пользователя.
• -c — Служит для указания команды для выполнения (для указанного юзверя).

Запустить команду от другого пользователя в Unix/Linux — способ 3

И так, можно использовать утилиту runuser. Команда runuser запускает оболочку с заменяющими идентификаторами пользователей и групп. Эта команда полезна только когда вы залогинены как пользователь root. Синтаксис выглядит следующим образом:

Как пример, я покажу следующую строку:

PS: Для использования команды runuser пароль не требуется, и он должен запускаться только пользователем root.

• -l: Создаст оболочку для входа в систему, используя файл runuser-l PAM вместо стандартного.
• -g: Указывает на основную группу.
• -G: Указывает на дополнительную группу.
• -c: Собственно, служит для указания команды.
• –session-command=COMMAND: Передает одну команду в оболочку с опцией «-c» и не создает новый сеанс.
• -m: Не сбрасывайте переменные среды (ENV).

Вот и все, тема «Запустить команду от другого пользователя в Unix/Linux» завершена.

5 thoughts on “ Запустить команду от другого пользователя в Unix/Linux ”

> $ sudo -H -u Your_another_user bash -c ‘ping linux-notes.org’

Смешались sudo и bash:

$ sudo -u user echo a
a

$ bash -c ‘echo a’
a

Да, уже поправил. Моя опечатки. Спасибо)

su asterisk -c «xxx»
This account is currently not available.

У меня вот проблема. Надо, чтобы звук из одной сессии (x2go)
Было слышно в другой сессии. Наверное даже не так.
Некоторые программы запускаются при загрузке ПК от user1.
Когда входишь через x2go тем же user1 звук (сигнализация) от этих демонов не слышно. Всю башку сломал. Подскажите пож как решить.

sudo -u www-data pwd

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник

Лучшая практика для запуска службы Linux от имени другого пользователя

Службы по умолчанию запускаются как root во время загрузки в моем окне RHEL. Если я правильно помню, то же самое верно и для других дистрибутивов Linux, которые используют сценарии инициализации в /etc/init.d .

Какой, по вашему мнению, лучший способ вместо этого запускать процессы как (статический) пользователь по моему выбору?

Единственный метод, к которому я пришел, — использовать что-то вроде:

Но это кажется немного неопрятным .

Есть ли какое-то волшебство, которое предоставляет простой механизм для автоматического запуска служб, как другие, не являющиеся пользователями root?

EDIT: Я должен был сказать, что процессы, которые я запускаю в этом случае, являются либо скриптами Python, либо Java-программами. Я бы предпочел не писать нативную оболочку вокруг них, поэтому, к сожалению, я не могу вызвать setuid () as Black предлагает.

В Debian мы используем утилиту start-stop-daemon , которая обрабатывает pid-файлы, изменяет пользователя, переводит демон в фоновый режим и многое другое.

Я не знаком с RedHat, но утилита daemon , которую вы уже используете (которая определена в /etc/init.d/functions , кстати), упоминается везде как эквивалент start-stop-daemon , поэтому либо она может изменить uid вашей программы, либо То, как вы делаете это уже правильно.

Если вы посмотрите вокруг сети, есть несколько готовых упаковок, которые вы можете использовать. Некоторые могут даже быть упакованы в RedHat. Посмотрите на daemonize , например.

Изучив все предложения здесь, я обнаружил несколько вещей, которые, я надеюсь, будут полезны другим на моей должности:

прыжок правильно указать мне назад at /etc/init.d/functions : функция daemon уже позволяет вам установить альтернативного пользователя:

Это реализуется путем переноса вызова процесса С runuser — Подробнее об этом позже.

Джонатан Леффлер прав: В Python есть setuid:

Однако я все еще не думаю, что вы можете установить setuid .__ изнутри JVM.

Ни su , ни runuser Изящно не справляются со случаем, когда вы Просите выполнить команду от имени пользователя Уже. Например.:

Чтобы обойти это поведение su и runuser , я изменил свой сценарий инициализации на что-то вроде:

Спасибо всем за помощь!

• Некоторые демоны (например, Apache) делают это самостоятельно, вызывая setuid ()
• Вы можете использовать setuid-file flag для запуска процесса от имени другого пользователя.
• Конечно, решение, которое вы упомянули, также работает.

Если вы намереваетесь написать свой собственный демон, я рекомендую вызвать setuid () . Таким образом, ваш процесс может

1. Используйте его привилегии root (например, открывайте файлы журнала, создавайте файлы pid).
2. Отбросьте свои привилегии root в определенный момент при запуске.

Просто чтобы добавить некоторые другие вещи, которые нужно остерегаться:

• Sudo в сценарии init.d не годится, так как ему нужен tty («Sudo: извините, у вас должен быть tty для запуска Sudo»)
• Если вы демонизируете Java-приложение, вы можете рассмотреть Java Service Wrapper (который предоставляет механизм для установки идентификатора пользователя)
• Другой альтернативой может быть su —session-command = [cmd] [пользователь]

на виртуальной машине CENTOS (Red Hat) для сервера svn: отредактировано /etc/init.d/svnserver чтобы изменить pid на что-то, что svn может написать:

и добавил опцию —user=svn :

Исходный pid-файл был /var/run/svnserve.pid . Демон не запускался, потому что только root мог писать туда.

Некоторые вещи, на которые стоит обратить внимание:

• Как вы упомянули, su запросит пароль, если вы уже являетесь целевым пользователем.
• Аналогично, setuid (2) завершится ошибкой, если вы уже являетесь целевым пользователем (в некоторых ОС)
• setuid (2) не устанавливает привилегии или элементы управления ресурсами, определенные в /etc/limits.conf (Linux) или/etc/user_attr (Solaris)
• Если вы идете по маршруту setgid (2)/setuid (2), не забудьте вызвать initgroups (3) — подробнее об этом здесь

Обычно я использую/sbin/su для переключения на соответствующего пользователя перед запуском демонов.

Почему бы не попробовать следующее в сценарии инициализации:

Источник