> Проблема не в том, что процесс OpenSMTPD запускает какие-то субкоманды шелом, а в том, что недостаточно хорошо проверяет входные данные.

Не совсем. То что он недостаточно хорошо проверяет -- это проблема. Но то, что он запускает субкоманды шеллом -- это тоже проблема. Если ты написал функцию pipe_to_mda(...) то эта функция должна запускать mda и только. Если при специально подобранных аргументах она может запустить не только mda, а ещё и "rm -rf /*", то это проблема. Может быть лишь потенциальная, но проблема.

Безбажного кода не бывает -- все это знают, но мало кто понимает. То, что безбажного кода не бывает означает, что если твоя pipe_to_mda может при специально подобранных аргументах вызвать "rm -rf /*", то тебе не удастся доказать, что твоя программа не запустит "rm -rf /*" ни при каком вводе.

Тут на деле встаёт вопрос ко всему проект OpenBSD: они не могут не знать, что exec на sh -- это штука, без которой сложно обойтись в unix. И они не могут не знать, что эта штука -- постоянный источник дыр в unix'овом софте. Если присмотреться, то корень проблемы в том, что при передаче аргументов через exec эти аргументы приходится кодировать в шелловские строки и чтобы sh потом декодировал их по своим заморочным правилам. То есть, образно говоря, надо собрать строку-скрипт и выполнить на неё eval. execle чуть лучше в этом смысле, чем system, но как показывает даже эта новость -- ненамного. И есть ведь напрашивающийся способ борьбы с этой проблемой: нужно взять и реализовать некое подмножество sh в виде C'шной библиотеки. Чтобы можно было бы написать, например:

sh_c("mail.local", "-f", from, to)

и быть уверенным, что это приведёт к тому, что будет создан процесс mail.local с argv вида {"mail.local", "-f", from, to}.

Можно и с пайпами как-нибудь разрулиться, даже несмотря на убожество C, например:

shellcommand_t base_cmd = sh_cmd("mail.local", "-f", from, to);
shellcommand_t pipe_cmd = sh_pipe_from(command_input, base_cmd);

sh_spawn(pipe_cmd);

Да, из-за отсутствия параметризации типов в C, тут возможно придётся создавать типы чьи размеры будут неизвестны на этапе компиляции, и из-за этого придётся дёргать malloc почём зря, да ещё и оптимизации пойдут лесом, но, во-первых, может если подумать можно сделать всё не настолько плохо, во-вторых, какая разница: надо очень постараться, чтобы это получилось медленнее, чем старт шелла.

Да, тут возможны проблемы с обработкой ошибок -- библиотека внутри будет дёргать много сисколлов, каждый из них может возвращать коды ошибок, и как-то надо эти ошибки прокидывать в код, дёргающий API библиотеки. Там опять же придётся повозиться и отсутствие параметризованных типов нисколько не упрощает эту возню. Но если всё совсем плохо, можно все сисколлы вызывать непосредственно из sh_spawn, и возвращать оттуда структурку описывающую результат, и к ней грядку методов для разгребания этого результата.

Да, такая библиотечка не решит всех проблем. Например, если mail.local при специально подобранных from и to будет вызывать "rm -rf /*", то тут ничего не сделаешь на уровне библиотеки.

Но фишка-то в том, что проблемы экранирования специсимволов шелла прекратят существовать. Потому что экранирование будет не нужно. Одна библиотека устраняет целый класс ошибок, довольно распространённых причём. Почему OpenBSD до сих пор не написала такую библиотеку и не перевела весь свой код на её использование, вместо всех этих system да execle -- мне не ясно. Подозреваю, что это юниксвей головного мозга.