Дозволити групі non-sudo контролювати завдання Upstart


11

Я намагаюся налаштувати завдання Upstart для запуску під час запуску системи, і це також можуть бути запущені / зупинені членами іншої групи sudo. З попередньою версією я використовував update-rc.dі скрипти, які зберігаються в /etc/init.d/цій роботі, додаючи %Group ALL = NOPASSWD: /etc/init.d/scriptnameдо свого файлу sudoers, але я не можу отримати еквівалент, що працює для Upstart.

Я намагався додати %Group ALL = NOPASSWD: /sbin/initctl start jobnameдо файлу sudoers, але спроба запуску команди start jobnameвидає цю помилку:

start: Rejected send message, 1 matched rules; type="method_call", sender=":1.21" (uid=1000 pid=5148 comm="start jobname " interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")

Наскільки я можу сказати, це скарга на те, як мій обліковий запис користувача не має права надсилати повідомлення "Пуск" у файлі конфігурації D-Bus для Upstart. Я не зміг знайти фактичну інформацію про те, як редагувати цей файл, щоб дати груповий дозвіл на доступ до певної послуги - чи існує така опція? Чи є спосіб редагувати файл Sudoers, щоб я міг запустити завдання без редагування файлу конфігурації? Чи краще мені дотримуватися попередньої версії?

Відповіді:


7

Ви можете почати з того, щоб дізнатись, де зберігається конфігурація D-Bus, специфічна для Upstart. Бачите цей destination="com.ubuntu.Upstart"фрагмент із повідомлення про помилку? Тепер спробуйте зімкнути його в папці з конфігураційними файлами D-Bus:

vhost07:~ $ grep -r "com.ubuntu.Upstart" /etc/dbus-1
/etc/dbus-1/system.d/Upstart.conf:    <allow own="com.ubuntu.Upstart" />
[...skipped...]

Цей Upstart.confфайл містить кілька прикладів політики. Я думаю, ви могли б спробувати розібрати з них формат політики. Потім спробуйте дозволити вашому конкретному користувачеві лише ті дії, які йому потрібні. Наприклад, як у:

<policy user="pope_benedict">
  <allow send_destination="com.ubuntu.Upstart"
         send_interface="com.ubuntu.Upstart0_6.Job"
         send_member="Start"/>
</policy>

Це повинно дозволити pope_benedictкористувачеві розпочати цю роботу.

Зауважте, що значення атрибутів політики "дозволити" перераховані у вихідному повідомленні про помилку.


1
О, і не забудьте перезапустити D-Bus після цього! :)
Іуліу Паскару

Я вважав це трохи дивним
Майк Кемпбелл

7

Я особисто використовую такий рядок у файлі /etc/sudoers.d/jobname_myuser:

myuser ALL = (root) NOPASSWD: /sbin/start jobname, /sbin/stop jobname, /sbin/restart jobname, /sbin/status jobname

як описано тут: /server//a/390723/68608


2

Такого варіанту у судо немає.

Різниця між скриптами Sysv та файлами конфігурації Upstart полягає лише в тому, що: скрипти Sysv - це сценарії, виконувані файли самостійно, і ви можете сказати sudo, щоб дозволити деякій групі їх виконувати. З іншого боку, конфігураційні файли Upstart - це просто файли конфігурації, а не виконувані файли, тому виконання start(symlink to initctl) - це те, що дозволяє sudo. Ваша проблема тут полягає в тому, що дозволяючи людям бігати, initctlви дозволяєте їм initctlвсе.

Рішення хоч і просте, якщо ви заклопотані лише однією роботою. Складіть сценарій, скажіть /usr/bin/jobname.shз

#!/bin/sh
initctl $1 jobname

потім chmod 755 /usr/bin/jobname.shі, нарешті, додайте цей виконуваний файл у файл sudoers:

%Group ALL = NOPASSWD: /usr/bin/jobname.sh

Таким чином, кожен може зателефонувати jobname.sh startабо jobname.sh stopконтролювати цю конкретну роботу. Ви можете додати деякі перевірки , щоб тільки startі stopпараметри і т.д.


Іншими словами, моя проблема полягає не в тому, що система забороняє членам групи можливість запускатись initctl, а те, що Upstart відмовляється від будь-яких сигналів, що надсилаються користувачами / групами, не отримавши явного дозволу введення політики в Upstart.conf? І немає ніякого способу надати більш детальну деталь, ніж параметр «всі завдання» чи «ні» у конфігураційному файлі?
Angle O'Saxon

Initctl у вашому випадку працює нормально навіть без зміни sudoers, Upstart просто відмовляється від повідомлень від нього, якщо ви спеціально не дозволите це для користувачів, що не користуються коренем. Дивіться інші дві відповіді. Ви можете визначити політику dbus на основі роботи (див. com.ubuntu.Upstart0_6.<JOB>Частину) в Upstart.conf. Залежно від ваших потреб, може бути простішим зробити такий сценарій для нього замість написання політики dbus і перезавантаження dbus і т. Д. Політика Dbus, очевидно, "правильна" річ, але залежно від конкретного випадку простий сценарій може мати довгий шлях з меншими клопотами.
Туміноїд

Редагування політики DBus для використання com.ubuntu.Upstart0_6.jobnameв якості send_interfaceвиробленого ж повідомлення про помилку, як і раніше. Якщо я маю рацію здогадуватися, що вихід помилки містить інформацію про сигнал, схоже, інтерфейс або пункт призначення не відображають послугу Upstart, на яку посилається сигнал. Я думаю, що інформація про службу - це лише аргументи в повідомленні про виклик методу D-Bus, і я не впевнений, що я можу редагувати політику D-Bus для Upstart для прийняття рішень на основі значень аргументів.
Angle O'Saxon

Сценарій такого типу, який ви пропонуєте, працює для мене досить добре, з одним застереженням: мені потрібно було запустити його так sudo jobname.sh start, щоб Upstart бачив запит, як надходить від користувача. rootЯ намагаюся зробити це це "правильний" спосіб (таким чином, в першу чергу відійдіть від сценаріїв Sys-V), тому я хотів би переробити це за допомогою політики D-Bus або іншої опції конфігурації Upstart, але якщо я не можу працюй так, я прийму цю відповідь.
Angle O'Saxon

1
Я також цитую "$1". З вашим [ "$1" = "start" -o "$1" = "stop" ]тестом я вважаю, що це безпечне, але без котирування $1розширення у сценарії, оскільки root - це лише нездорова звичка (якщо навмисне не хочеться розщеплення слів) ...
Бені Чернявський-Паскін

0

Як було зазначено вище, демон dbus має файл конфігурації, який спеціалізується на певній програмі.

ls /etc/dbus-1/system.d/
avahi-dbus.conf
bluetooth.conf
...
Upstart.conf
wpa_supplicant.con

Файл конфігурації також встановлює обмеження ресурсів, параметри безпеки тощо.

Докладніше див. Dbus-daemon-1 (1) - Сторінка користувача Linux

Щоб дозволити групі запускати / зупиняти завдання для запуску, додайте до /etc/dbus-1/system.d/Upstart.conf наступну політику

  <policy group="YourGroupName">
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Start" />
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Stop" />
  </policy>

Ви повинні врахувати наслідки такої політики для безпеки перед тим, як змінити політику за замовчуванням. Члени YourGroupName зможуть запустити / зупинити всі завдання Upstart.


Але чи є спосіб обмежити роботу, яку вони можуть контролювати? Або це неможливо, оскільки D-Bus не звертає уваги на вміст повідомлення?
Angle O'Saxon

Я спробував додати цю політику до Upstart.conf (замінивши ім'я групи моїм фактичним іменем групи), перезапустив D-Bus і отримав, start: You do not have permission to modify job: jobnameколи я намагався запустити послугу.
Angle O'Saxon

В ПОРЯДКУ. Це означає, що політика успішно застосовується. Схоже, що yourjob.conf знаходиться в / etc / init. Завдання користувачів повинні бути в ~ / .init. Чи правдоподібно у вашому випадку розмістити yourjob.conf в ~ / .init?
Горан Мішкович

Що стосується вашого першого питання: Політика визначає, до яких інтерфейсів та членів можна отримати доступ. Він визначає, який вміст / аргументи можна надсилати / передавати. Нинішня обмежувальна політика знижена вгору за течією. Дивіться, не можна піднятися на роботу із користувачем
Горан Мішкович
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.