Права на передачу сигналов

думаю план такой:

если доступа к исходному коду root-демона нет — то создать нового root-helper-думона, который слушает сигналы по шине dBus, в том числе от НЕпревелигерованного пользователя и передаёт их нашему root-демону.

держать постоянно-включенным root-helper-думона не обязательно. можно настроить его запуск по требованию (средствами самого dBus).

через dBus шину можно поглядеть идентификатор пользователя который отсылает сигналы. и таким образом принимить сигналы НЕ от всех непревилегированных пользователей а только от определённых пользователей (у которых определённая группа).

вобщем такие дела.

план Б: использовать unix-domain-sockets , находящиеся в определённой директории.

если доступа к исходному коду root-демона нет

Есть! Есть и код и полное понимание его функциональности.
Нет вот только опыта работы с сигналами.

Есть! Есть и код и полное понимание его функциональности.

ну тогда всё просто.

план Ц: не использовать сигналы.

:-D

man sudo

man sudoers

план Ц: не использовать сигналы.

(сразу использовать dBus или unix-domain-sockets)

ну тогда всё просто.

Подскажи плиз.
Кусок кода, отвечающий за обработку сигналов прилагаю к делу:)

то создать нового root-helper-думона, который слушает сигналы по шине dBus

а нафига тут dbus? открыл fifo, и слушай себе, сколько влезет

а нафига тут dbus? открыл fifo, и слушай себе, сколько влезет

тоже вариант.. да... :)

и кстате sudoers тоже хорошо придумал.

(сам-то я не очень люблю пути повышающие привелегии.. но sudoers меньшее из зол, наверно)

пути повышающие привелегии

Да вот в этом-то и дело.
Демон-то хоть и вынужден работать из-под рута, но управляться должен кем попало.

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

дать беспарольный sudo на одну команду, и загнать в /etc/profile.d какой-нибудь сниппет с alias cmd='sudo cmd' - не проблема

Гм. Предполагается что демон будет работать на разных машинах и для разных людей.
Никто в трезвом уме и светлой памяти не будет проводить подобные шаманства.

а при чем тут шаманства? нужный конфиг для sudo кладется отдельным файлом в /etc/sudoers.d, алиас - в /etc/profile.d. все оформляется пакетом и ставится куда угодно без лишних телодвижений.

В принципе да, все эти шаманские па я могу взять на себя, но меня не оставляет смутное сомнение в правильности этого пути.

ну, ты разраб - тебе решать

Демон, просчитывающий план по захвату вселенной, работает из-под рута

Вдоль, срочно! Демонам надо делать отдельного пользователя с правом на запись нужного файла и доступам к нужным устройствам.

Почему бы не сделать

setcap 'CAP_KILL+eip'

?

отдельного пользователя

Мне надо писать в /dev/vcs.
Зачем мне ещё один пользователь?

setcap 'CAP_KILL+eip'

Разжуй, плиз, подробней. Я не догоняю что это делает.

Дает непривилегированному процессу право посылать сигналы кому угодно.

гм.
/me пошёл курить маны.

Почему бы не использовать сокеты?

А как юзер из консоли будет УДОБНО управлять демоном?

А что тут такого? Пишешь скрипт/программу отправляющую команду в сокет демона, команда отправляется по результатам параметров программы/скрипта. Пример mysql (консольный клиент для MySQL).

Т.е. ты предлагаешь написать программу для управления программой?
При этом масштабы управления ограничиваются одним событием — сигнал переключает режим работы демона.
Не-не-не. Я так не играю:)

программу для управления программой

Настолько конечно я баша не знаю, чтоб сходу пример навелосипедить, но думаю на нем это займет 3 строчки.

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

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

А как юзер из консоли будет УДОБНО управлять демоном?

Так уж сложилось, что unix signals не обладают никакими DAC/MAC, помимо проверки id. Сигналы сами по себе вещь в себе, и у них куча других тонкостей (если не сказать проблем). Поэтому, как тут предлагалось, лучшее решение это unix socket/fifo, таким образом вы получаете имя (или целый файл), после чего можете применять к этому имени любые политики, хоть selinux.

fifo используют init (/dev/initctl), mpd, и куча демонов.

А CAP_KILL это не решение, так как всё равно кто-то (root) этот cap_kill должен установить, и этот CAP_KILL будет распространяться на всю систему (то есть процесс будет способен убить init, например).

А CAP_KILL это не решение

Это скорее заглушка, если нет желания/возможности разбираться с кодом демона. Процесс, естественно, отдельный. Чтобы никого случайно не прибил. У меня стоит такая штука

#include <sys/types.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>

int main()
{
    pid_t pid;
    FILE *f = fopen("/var/run/daemon.pid","r");
    if(!f) exit(-2);
    if(fscanf(f, "%d", &pid)!=1) exit(-2);
    return kill(pid,1);
}