03.12.08
dovecot: xexec.
Немного в продолжение предыдущего поста. Я обещал написать про
xexec. В процессе все тех же поисков рулеза нашел в документации
dovecot’а информацию про этот модуль. Помечен, как
экспериментальный, но мне думается не в силу качества кода,
а в силу того, как они сами написали, что его действия не попадают в стандарты rfc по imap протоколу и, соответственно, не поддерживаются никакими клиентами.
Имхо, замечательная вещь, возможно, в будущем панацея для системных администраторов почтового сервера. Собственно описание можно ограничить одной фразой с сайта:
“Execute any server side application and communicate with it through plugins over IMAP”
Для начала немного примеров:
# telnet 127.0.0.1 143
Trying 127.0.0.1…
Connected to 127.0.0.1.
Escape character is ‘^]’.
* OK Dovecot ready.
001 login viliar@dungeon.local xxxXx
001 OK Logged in.
002 xexec user
* OK User: viliar@dungeon.local, effective uid: 2003
002 OK command exited successfully
Теперь чуть подробнее
003 xexec more
* OK Dovecot gave next info about you:
* OK your account viliar in domain dungeon.local
* OK home at /home/mail/dungeon.local/viliar/ and your uid 2003
* OK connected by IMAP service
* OK local ip 127.0.0.1, your ip 127.0.0.1
003 OK command exited successfully
То есть плагин используется в контексте пользовательского процесса, с
его привелегиями! Теперь давайте вспомним, что я писал про passwd-like файлы. Можно на стороне нарисовать очень простой интерфейс, который будет проверять полученные данные от довекота о пользователе, проверять входные данные и менять файлы конфигурации, которые созданы под его юидом. Никакого доступа к чувствительной информации. Кайф? Не то слово.
Ну и так, до кучи поменяем пароль:
004 xexec chpass XdaRT34
* OK password successefully updated
004 OK command exited successfully
005 logout
* BYE Logging out
005 OK Logout completed.
Connection closed by foreign host
На стороне сервера это будет выглядеть примерно таким образом:
/etc/dovecot/dovecot.conf
plugin {
quota = maildir:ignore=Trash
xexec = date:/usr/local/bin/date
xexec2 = user:/usr/local/bin/user %u
xexec3 = chpass:/usr/local/bin/chpass %u
xexec4 = more:/usr/local/bin/more.sh %n %d %s %p %l %r %h %i
}
Скрипты могут быть любыми, хоть как тут для примера, на баше. Это не то узкое место, где обязательно нужно оптимизировать, потому что эти скрипты не будут так часто запускаться и обрабатывать бешенные обьемы информации, как какой-нибудь демон типа spamassassin, которому с точки зрения ресурсов стоит предпочесть написанный на сях dspam.
Плюсы очевидны. Гибкость и безопасность. Если, условно, сравнить с postfixadmin, хотя это сравнение, я понимаю, не очень корректно, так как сравнивается протокол и интерфейс администрирования. Скорее я сравниваю и то и другое как возможность администрирования почтового сервера и это касается скорее не самого postfixadmin’а, а методов работы таких “вебморд”.
У них, как правило, конкретная привязка к определенному типу хранилища. Ну может быть к нескольким однотипным, на основе sql. Postfixadmin работает только с mysql. Это ограничивает нас существенно. И этому, возможно, очень замечательному интерфейсу я должен дать _полный_ доступ до базы. Это самое ужасное. При возникновении дыр в нем самом, или специфических дыр в php в этом случае можно, простите за выражение, огрести по полной. При совокупности дыр, через mysql, если кому-то придет нелепая идея использовать его еще для чего-то, можно тоже
получить и утечку данных и все-такое. Но это уже из области допущений и можно в расчет не принимать. Но все равно несекурно
совсем как получается. Можно ограничить доступ до административного интерфеса при помощи basic auth и вобще заставлять пользователей ходить только через https. Таким образом мы уменьшаем число потениальных взломщиков только до числа зарегистрированных пользователей. Но это из разряда вспомогательных решений и не хотелось бы надеяться только на дополнительные меры. Хочется секурного “из коробки”, чтобы в основании были более безопасные методы работы с информацией.
При использовании xexec мы получаем возможность использовать любой интерфейс на стороне сервера и на стороне клиента, то есть веб-приложения. Написать, например, модуль для squirrelmail. И это будет
значительно более безопасное решение, потому что веб-интерфейсу мы не даем ключ от квартиры пароль от базы, где лежат
все данные. Ну а если доводить идею об безопасности до абсурда, то сквирмейл, во избежания модификации скриптов, если будут дыры - держать на read-only разделе с единым профилем для всех. Шучу. 
Это так, немного информации к размышлению и очередной бонус
активно развивающемуся проекту dovecot. Модульность рулит