IPC между приложениями запущенными от разных пользователей.

http://linux.die.net/man/8/coroipc_overview

Unix-сокеты не подойдут? FIFO?

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

А на сколько распространен d-bus? Его можно установить отдельно без перекомпиляций ядра и прочих затратных операций?

d-bus

Зря ты это сказал.

shmem? Права, по-моему, там настраиваются.

Я юзаю Qt у меня всё хорошо, так что не надо флудных мессажей, меня интересует вопрос на сколько удобно будет пользователю если я буду использовать d-bus. Вариант с сокетами мне не нравится, т.к. я не вижу удобного способа синхронизировать настройки - какой порт для него использовать. Приложение это служба, предоставляющая информацию своим клиентам. Служба запущена от имени root, клиенты от любого пользователя. Можно конечно предоставить доступ к файлам конфига на чтение всем пользователям, но это делать бы не хотелось как и вообще заморачиваться с нестандартной для фреймворка системой настроек. Fifo позволит обеспечить IPC для такой связки?

Я юзаю Qt у меня всё хорошо

Мы рады за тебя.

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

У UNIX-сокетов нет порта, а какую-то «точку встречи» ты всё равно должен будешь задать (в случае Unix-сокета это имя файла).

Fifo позволит обеспечить IPC для такой связки?

Да.

если ты используешь Qt, то ты уже(скорее всего не подозревая об этом) используешь dbus, хотя и неявно

Я юзаю Qt

а там разве нету средств для подобного IPC?

если ты используешь Qt, то ты уже(скорее всего не подозревая об этом) используешь dbus, хотя и неявно

Откуда такие сведения ?

Есть возможность использовать d-bus и обычные сокеты. Локальные сокеты(под linux это вроде доменные сокеты) использовать не получается из приложений с разным userid, так же как и расшареную память.

Локальные сокеты(под linux это вроде доменные сокеты) использовать не получается из приложений с разным userid

можно. там с правами на доступ та же история, что и с правами на доступ к обычным файлам

признаю, немножко поспешил с выводами: dbus _точно_ используется Qt в случае, когда используется модуль QtGui

признаю, немножко поспешил с выводами: dbus _точно_ используется Qt в случае, когда используется модуль QtGui

Круто, а это проверенная информация? можно пруф и с какой версии Qt? если это так, то клиент в любом случае имеет GUI а значит и как IPC можно использовать d-bus, что в случае Qt вообщем то довольно удобно.

Локальные сокеты(под linux это вроде доменные сокеты) использовать не получается из приложений с разным userid

можно. там с правами на доступ та же история, что и с правами на доступ к обычным файлам

Ну да но в этом то и беда что получить доступ к дескриптору чего то через что это всё организованно, что бы права изменить, я из Qt не могу, а чем реализовывать на основе функционала линуксовых api, уже Qt-шные врапперы для d-bus использовать.

Служба запущена от имени root

Не надо так делать.

Что, даже в винде?

dbus _точно_ используется Qt в случае, когда используется модуль QtGui

Откуда дровишки? Графические приложения спокойно работают на машинах без DBus.

DBus в Qt используется только, как мне казалось, в модуле QtDBus.

Не надо так делать.

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

Вообщем как то не по делу тут разговор пошел, на данный момент меня интересует на каком количестве дистрибутивов сейчас есть d-bus, если на подавляющем или хотя бы на трендовых 2-3 летней давности то я буду юзать d-bus.

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

Опиши в общих чертах, зачем тебе рут.

В любом современном дистрибутиве (даже 2-3 летней давности) без упоротых на всю голову ментейнеров у руля.

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

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

отдельный маленький модуль, который и будет обладать правами рута

Вот это интересно, я видел один раз подобное решение(в МСВС), но не видел его исходников, это возможно было бы лучше всего. Но как сделать это технически я увы не в курсе.

А не прокатит кстати такой подход - читалка устройств остается экзешником. Клиент остается экзешником. Но они оба подгружают dll с синглтоном который сервер пишет, а клиент читает? Или для разных userid'oв будут 2 инстанса дллки загружены ?

Поумерьте ваш пыл, сударь. Есть множество способов решить проблему.

Собственно я и хотел узнать

what a best practice

да, с дллкой я это че то загнул, даешь каждому процессу своё адресное пространство.