Привет всем. Вот какая заковыка.В сокет-сервере я пытаюсь определить PID входящего соединения на локальном хосте. Если сервер запущен рутом, это можно сделать, анализируя содержимое /proc/PID/fd, так и поступают утилиты типа netstat. Но если сервер запущен от обычного пользователя, чужие fd могут быть недоступны. В /proc/net/tcp можно найти только UID.
Есть какие-нибудь идеи ? Система Linux, kernel 2.6.
>Привет всем. Вот какая заковыка.
>
>В сокет-сервере я пытаюсь определить PID входящего соединения на локальном хосте. Если
>сервер запущен рутом, это можно сделать, анализируя содержимое /proc/PID/fd, так и
>поступают утилиты типа netstat. Но если сервер запущен от обычного пользователя,
>чужие fd могут быть недоступны. В /proc/net/tcp можно найти только UID.
>
>
>Есть какие-нибудь идеи ? Система Linux, kernel 2.6.
По моему это не возможно, единственная возможность, это когда входящее соединение само сообщит свой ПИД.
Нафиг он тебе нужен?
>По моему это не возможно, единственная возможность, это когда входящее соединение само
>сообщит свой ПИД.
>Нафиг он тебе нужен?В свое время я сделал связку демонов, работающих на одном хосте. Демоны вызывают при необходимости спец-демон через сокет и получают соответствующую информацию. Решение получилось простым и модульным, достигалась хорошая балансировка по производительности и ресурсоемкости, так что трогать это не хочется. Однако выснилось, что если на хосте пасутся несколько пользователей с разными интересами, кто-нибудь может загружать этот спец-демон всякой глупостью. Поэтому пришлось искать простое решение для "верификации" полезных запросов на спец-демоне, без паролей и шифрации трафика.
Я подозреваю, что если нет соответствующих средств на уровне ядра (типа того, что выдается в procfs), то PID я в общем случае не получу. Сейчас верификация будет по-другому, в принципе, удовлетворительно. Но все равно интересно, может, как-то можно все же узнать этот самый PID.