> Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`).Описанная проблема понятна, её разработчики OpenSMTPD пытаются решать списком допустимых символов и эскейпингом. Т.е. вызвать тот же rm таким способом, как ты описал, в конкретном случае не получилось бы.
> Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход.
> То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход.
Но ведь в данном случае, вызываемая программа и есть /bin/sh. И проблема не в том, что мы передали что-то не то в /usr/libexec/mail.local, а в том, что мы завершили shell-команду символом ";" и выполнили (ошибочно) кусок того, что после ";" с правами локального юзера, которому предназначалось письмо.
> Я говорю не об универсальной библиотеке, экранирующая спецсимволы, я говорю о /bin/sh в виде подгружаемой библиотеки. В некотором смысле, семантически это sh, но с другим синтаксисом. Этот синтаксис более многословный и неудобный для использования в командной строке, и вообще без компиляции с ним не поработаешь. Зато он оптимизирован на избегание _распространённых_ проблем вызванных ошибками экранирования.
Я несколько неверно высказался, что проблема в неверной валидации входных данных. Ну то есть это так, но "[функция] smtp_mailaddr() имеет логическую ошибку, из-за которой в случае передачи пустого домена в email, функция возвращает успешный код проверки, даже если часть адреса до "@" содержит недопустимые символы" - это не то, что можно было бы пофиксить условной libsh.
Я вообще не уверен, что есть серебрянная пуля, защищающая от подобного рода ошибок.
Условная libsh, в зависимости от того, как она будет сделана, может быть и будет решать какие-то типовые проблемы, в то же время, ИМХО, в бОльшей части случаев практичнее просто ответственно подходить к валидации входных данных, а не использовать комплексные решения (unix-way головного мозга, да).
