одним из логических решений была бы ПОЛНАЯ блокировка канала(при его использовании) на чтение одним процессом. возможно ли это с точки зрения безопасности?

Видимо всё-таки имелось ввиду межпроцессное взаимодействие, а не межпроцессорное. Способ для *nix существует, как буду дома - отпишусь.

__________________

..когда же кто-нибудь выпустит MD5(Unix) брутер на GPU.... жду....

заранее спасибо

да блин, через банальные пайпы с асимерт. шифр. =)

>>да блин, через банальные пайпы с асимерт. шифр. =)
я ищу способ, не затрагивающий шифрования. кстати, я подумал, и шифрование тоже внедрить сложно: даже используя алгоритм диффи-хеллмана для генерации ключа симм. шифра не смог найти способа нужной идентификации клиента-процесса.. чтобы шифрованное сообщение дошло в "те руки".
забавно, но только сейчас вспомнил о unix-сокетах, попробую посмотреть

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

__________________

..когда же кто-нибудь выпустит MD5(Unix) брутер на GPU.... жду....

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

Вот, собственно я нащёл что искал. В книге Р.Стиверса "unix - Взаимодейсвие процессов" читай пункт 3.6 "Повторное использование идентификаторов".
Надеюсь, поможет.

__________________

..когда же кто-нибудь выпустит MD5(Unix) брутер на GPU.... жду....

а при чем здесь это? у меня серверная часть имеет вполне открытое и постоянное имя ipc на файловой системе, поэтому злоумышленник может вполне добросовестно получать дескриптор ftok("server") меня интересует как перехватить посланное сообщение к серверной части первым, то есть самим сервером.
очень красивая модель unix-sockets, но опять же - не могу найти способа идентификации программы-клиента. в принципе, используя концепцию сокетов это становится основной проблемой тк вклиниться в существующее соединение по-теории, как я понимаю невозможно.
теоретически на пальцах это должно выглядить так: клиент, при подключении, отправляет свой pid, серверная программа проверяет его принадлежность к доверенным процессам и отправляет случайное число, которое должно каким-то образом отобразиться в адресном пространстве процесса или где-то еще, но чтобы это подтверждало, что это тот самый процесс, с отправленным pid, если это происходит, то очевидно что на подключении доверенный процесс.
тут логично было бы использовать разделяемую память, однако в поставленной задаче процесс-злоумышленника может быть вполне запущен от пользователя процесса-клиента и если при создании shmget, например, указать бит w для владельца, без чего записывать в эту область у нас не будет прав, то все процессы этого пользователя смогут туда писать...
мысль вторая, клиент, после получения случайного числа, ставит дополнительно бит записи в /proc/pid, создает там сокет /proc/pid/RANDOM и общение происходит уже по нему, снимает бит записи с каталога.. вполне возможно, что это решение.