LINUX.ORG.RU

Клиент серверное взаимодействие внутри одной машины

 , , ,


0

1

Всем привет. Я тут пишу маленький сервис для своих нужд, который будет крутиться демоном на машине и cli утилиту, которая будет им управлять. Вопрос собсна как правильно связать утилиту и демона? Мне на ум приходят shared memory и порты. Порт это конечно очень удобно, но мне хотелось бы быть уверенным, что демон получил сигнал именно от утилиты с той же машины, где демон крутится, а не откуда-то из сети. Если это удалось выяснить, как убедиться, что сигнал подала утилита запущенная от нужного юзера, например рута? Понятно, что я могу клиент-серверное взаимодействие обмазать сертификатом и в http запросе его проверять, например, но мне кажется, что эту задачу можно решить как-то проще. Как в принципе такую задачу принято решать в линуксе?

★★★★★

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

rumgot ★★★★★
()

А если хочется подолбаться - boost interprocess

invy ★★★★★
()

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

Unix-сокеты + SO_PEERCRED/SCM_CREDENTIALS.

Как в принципе такую задачу принято решать в линуксе?

А вообще — D-Bus.

/thread

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Я не хочу использовать дополнительное приложение(это про dbus)

Aswed ★★★★★
() автор топика
Последнее исправление: Aswed (всего исправлений: 1)

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

AKonia ★★
()

Если ты отделил сервер от клиента, то какая тебе разница, откуда твой клиент отправляет запросы? Задача твоего сервера теперь в том, чтобы опознать своего клиента, если это вообще теперь важно.
Для этого придумали аутентификацию всякими сертификатами, токенами и прочими секретами Полишинеля.

blexey ★★★★★
()

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

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

Я не хочу использовать дополнительное приложение(это про dbus)

и cli утилиту, которая будет им управлять

Ага-ага, а потом понадобится клиент с гуи или веб-морда или всё сразу пплюс удалённый доступ. Поэтому я за сокеты, порты или вообще ws.

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 2)

Если для своих нужд и ни с кем интегрироваться не надо - какая-нибудь готовая библиотека для JSONRPC. Они умеют работать поверх разных транспортов.

tailgunner ★★★★★
()

Unix socket же, сам так делаю, и счастлив

menangen ★★★★★
()

Что сложного в https?

Miguel ★★★★★
()

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

Интерфейс сокетов позволяет получить адрес клиента (для TCP getpeername , для UDP возвращается вместе с данными дейтаграммы.

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

В этом есть какой-то смысл с т.з. ИБ? Если рассматривать только стародедовские DAC фичи UNIX, можно тупо использовать именованную дудку, и разрешить в нее писать только руту. Это, конечно, никак не запретит злоумышленнику, получившему каким-то образом привилегии root посылать свои запросы твоим сервисам. Так что защита дешевенькая.

seiken ★★★★★
()

unix socket

anonymous
()
Ответ на: комментарий от seiken

Отдела ИБ нет) Я пилю тулзу для себя. Мне прост не хочется на своем сервере открывать лишние уязвимости. Энивей, я решил все делать через shared memory, т.к. для моей задачи функциональности хватит, а дополнительные расходы там минимальны.

Aswed ★★★★★
() автор топика

unix socket естественно. Сервер слушает /var/run/mycoolserver/control, утилита к нему коннектится, доступ регулируется правами - например 660 root:mycoolserver на сокет, пользователи которые могут управлять сервером добавляются в группу mycoolserver, либо утилита делается sgid mycoolserver, тогда управлять могут все, но только через неё. Либо делаются правда 666, тогда могут управлять все как угодно.

slovazap ★★★★★
()

Даже я знаю, что нужно использовать unix socket.
Shared memory, конечно, быстрее, но unix socket сильно проще и легко портануть на TCP, если понадобится.

Shadow ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.