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

Named pipes

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

https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BD%D0%BE%D0%B5_%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D0%B5

выбирай

thrift или grpc

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

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

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

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

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

/thread

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

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

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

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

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

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

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

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

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

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

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

nanomsg

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

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

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

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

unix socket

Предложил бы сразу ONC RPC!

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

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

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