Пользовательские идентификаторы пользователей Linux дифференцированы между ними. Реальные пользователи получают права доступа на какие-либо действия на основе сведений о том, кем они являются (владелец в некоторой группе и др.) в отношении объекта доступа. Значения пользовательских идентификаторов назначаются независимо на каждом компьютере, так что двум различным пользователям на разных машинах могут быть назначены одинаковые идентификаторы. Программы, использующие DIPC, нуждаются в исполнении кода на разных компьютерах - по большому счету, для доступа к структурам ядра. Их вызовы должны обеспечивать некоторый уровень безопасности в системе.
Для DIPC установлено, что пользователь, для которого обеспечивается защита исполнения удаленного системного вызова, должен быть известен на соответствующей удаленной машине под тем же логином. Исполнение удаленных вызовов программ DIPC предполагает наличие определенных эффективных пользовательских идентификаторов наряду с именем пользователя. Очевидно, что с целью обеспечения полезности, и даже значимости, это зафиксированное имя должно однозначно идентифицировать соответствующее лицо на двух машинах.
Единственным исключением из приведенного правила является пользователь root, который имеет максимальные полномочия на Linux-компьютере. Выполнение роли root на одной машине не налагает обязательств выполнять роль root на другой машине. По этой причине все пользователи root преобразуются в одного пользователя с именем dipcd. Администраторы могут контролировать этого пользователя путем корректировки его пользовательского и группового идентификаторов в отношении к другим группам. Программисты могут выбирать права доступа для структур IPC, чтобы разрешить или запретить доступ к ним.
Остерегайтесь случайных конфликтов имен в одном кластере, что может дать возможность неавторизированным пользователям влиять на структуры IPC других лиц. Администраторы должны гарантировать уникальность имени для конкретной персоны в пределах кластера.
Другой мерой безопасности, предложенной Майклом Шмицем (Michael Schmitz), является проблема избавления от вторжения злоумышленников в кластер DIPC. В файле /etc/dipc.allow перечисляются адреса компьютеров, которые могут быть частью кластера DIPC, т.е. ``надежных'' машин. Арбитр будет просто отбрасывать запросы от компьютеров, чьи адреса не находятся в данном файле. Опция -s (secure) заставит back_end также не выполнять никаких действий при запросах от ненадежных компьютеров (Обратитесь к файлу dipcd.doc для получения более подробной информации).
``Подделка'' IP-адресов при DIPC ``не пройдет''. Причиной этого является то, что dipcd всегда использует новые TCP-соединения для подтверждения запросов, т.е. дает подтверждение, что информация будет направляться достоверному компьютеру, а не ``самозванцу''.