Suid или не suid?
Sendmail может вполне безопасно сделан setuid на root. Тогда, когда он собирается запустить с помощью exec(2) почтовую программу, он проверяет, равен ли userid нулю; если равен, то он переустанавливает userid и groupid на значения по умолчанию (выставляемые равенством U= в строке почтовой программы; если это равенство не установлено, используется опция DefaultUser). Это может быть преодолено выставкой флага S у почтовой программы для доверенных почтовых программ, которые могут быть запущены от root. Однако, это заставит обработку почты быть засчитанной sa(8) как потребление пользователем root системных ресурсов, вместо того, чтобы засчитать это пользователю, посылающему почту.
Если вы не делаете sendmail setuid'ным на root, он все равно будет работать, но вы потеряете большиую часть функциональности и конфиденциальности, а так же вам придется открыть всем на запись каталог очереди. Также вы можете сделать sendmail setuid'ным на какого-либо псевдопользователя (например, создав пользователя "sendmail" и сделав sendmail setuid'ным на него) что исправит проблему конфиденциальности, но не вопросы функциональности. Также, это не будет являться гарантией безопасности: например, пользователь root посылает почту, и демон будет часто работать от пользователя root.
В качестве компромисса можно сделать sendmail setuid'ным на пользователя root, но выставить опцию RunAsUser. В результате это заставит sendmail стать указанным пользователем сразу же после запуска, требующего привилегии пользователя root (главным образом, открытия порта SMTP). Если вы используете опцию RunAsUser, каталог очереди (обычно /var/spool/mqueue) должен принадлежать этому пользователю, а все файлы и базы данных (включая пользовательские файлы .forward, файлы псевдонимов, файлы :include, и внешние базы данных) должны быть открыты для этого пользователя на чтение. RunAsUser скорее всего наиболее подходит для конфигурации на брандмауэрах, не имеющих регулярных заходов пользователей.
