/UNIX/ авторизация направления local delivery?

[netch]

Задумался тут над одной сугубо юниксовой задачкой (не-юниксоедам не читать;))

Представим себе MTA (mail transfer agent) доставляющий в том числе и на системные локальные аккаунты, который в состоянии отрабатывать разнообразные /etc/aliases, ~$user/.forward*, а в них конструкции вида :include: и доставку в файлы и на вход программ. Доставка в файлы должна делаться от прав того, кто написал соответствующее правило доставки, то есть кто владелец соответствующего файла форварда, алиасов или включаемого из них файла. Всё бы ничего, но есть ещё задача группировки доставок: например, письмо шло на a и b, a через /etc/aliases развёрнуто на x и y, b через файл включенный из ~b/.forward - на y и z, z доставляется пайпом на программу. Чтобы на y поступила только одна копия, кто-то должен объединить адресные списки. Предположим, что управляющий процесс для надёжности работает не от рута (у него очень много разной информации перерабатывается, и сделать ошибку в логике или просто переполнить буфер нефиг делать). Принимать от него любые утверждения вида "это письмо доставляем на вход программе /uuu/vvv запущенной от юзера ttt" стрёмно. Какие есть выходы из ситуации?

- Вообще не обрабатывать алиасы и форварды недоступные управляющему юзеру. Метод конечно хорош для отделённых хранилищ вроде cyrus или CGate, но не соответствует условиям задачи.

- Запускать управляющий доставкой процесс от рута и делать проверку прав вручную (ручной развёрткой путей, проверкой прав доступа на них, и так далее). Метод sendmail и exim. Проблемы: большая опасность пробоя через рутовый код; замена системной отработки на свою нивелирует часть системных возможностей (например, acl'ей на FS).
Можно это частично лечить через setreuid() с установкой effective uid на проверяемого сейчас, но вероятность эксплойта при пробое это не сильно снижает.

- Плюнуть на контроль дупов вообще и доставлять на один адрес столько раз сколько получится (на файлы адресов и прочие вложенности вызывая дочерний процесс). Это путь postfix. Проблемы с защитой нет, но получать одно письмо много раз не сильно приятно;(

- Информацию доставки подписывать криптографически, а на этапе реальной доставки письма проверять подпись. Безопасно, но может процессор сожрать так что мало не покажется.

- Информацию доставки складывать в "куки" с длинным случайным именем, передавая управляющему процессу только имя этой куки. Безопасно, но сожрёт дисковую подсистему.

- Процесс, отрабатывающий локальные алиасы/форварды, живёт не только этот этап, но и последующую фактическую доставку и запоминает список целевых адресов в себе. Плохо тем, что если доставка на такого получателя (который может быть в виде vasya@:prog:/home/vasya/lib/incoming_filter) срывается, то на следующий раз запомнить получателя уже не получится - потребуется новое раскрытие.

Какие ещё могут быть идеи?

Пока что мне кажется что если подпись сделать максимально дешёвой (например, md5 от конкатенации строки кодированного направления с фиксированной строкой) - это составит минимум потребления процессора и в то же время даст достаточный уровень защиты. Подбирать md5 в условиях влома в работающий процесс вряд ли кто будет, а если будет - там и sha256 подоспеет;)

Comments

[klinok.livejournal.com]

А если запоминать только ID последних 100 (или 1000 или сколько там надо) прошедших через систему писем? Ведь время между расшифровкой a и b измеряется отнюдь не часами. На это много ресурсов уйти не должно...

[netch]

Повторная доставка может быть и через час, если было уже много попыток. А темп прохода писем через систему может быть и десятками в секунду. Таким образом, помнить надо до миллиона id. Не выход.

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

[livsy.livejournal.com]

Я думаю, что стоит забить на дупы. Во-первых это самый простой для реализации и защищённый способ, а во-вторых всё таки соблюдается принцип "делай что сказано" -- мало ли зачем нужно дублировать письма.

[nestor-asa.livejournal.com]

- Плюнуть на контроль дупов вообще и доставлять на один адрес столько раз сколько получится (на файлы адресов и прочие вложенности вызывая дочерний процесс). Это путь postfix. Проблемы с защитой нет, но получать одно письмо много раз не сильно приятно;(

Писал я патч к postfix, который решает проблему дупов в похожей ситуации...

[nuclight.livejournal.com]

Использовать вариант с куками, разгрузив дисковую подсистему - пишется процесс-"хранитель кук" в памяти. Поизвращаться с анонимными mmap() и т.д.

[netch]

Куки должны быть валидными в течение недели как минимум и не зависеть от перезагрузок и перезапусков. При этом мне идея такого хранителя сильно не нравится.

[nuclight.livejournal.com]

SQL-база? :))

[netch]

Не слишком ли навёрнуто?
Идея недельного пула хук (звучит-то как;)) мне кажется наиболее работоспособной.

На то и смайлики

[nuclight.livejournal.com]

На самом деле я оригинальный пост не читал, а просмотрел по диагонали, и выдал первое пришедшее в голову ;) С целью оптимизации наиболее понравившегося варианта [вспоминает тред про очистку /tmp] методом эмуляции части дисковой подсистемы самостоятельно. Если бы юниксовые FS могли хранить данные прямо в инодах, как NTFS, нагрузка была бы существенно меньше.

Re: На то и смайлики

[netch]

> Если бы юниксовые FS могли хранить данные прямо в инодах, как NTFS, нагрузка была бы существенно меньше.

Тут иноды маленькие. Но короткие симлинки на UFS именно так и хранятся.

Re: На то и смайлики

[nuclight.livejournal.com]

Если бы не только симлинки и device major/minor numbers, а и обычные данные - можно было бы о чем-то говорить. Хотя 60 байт (120 для UFS2) всё же маловато будет.

P.S. Кстати, нет описания адресации фрагментов и блоков на UFS ? Эксперимент над 5-Мб vn-диском на 4.11 показал, что в dinode хранятся адреса фрагментов, а не блоков. Я в недоумении - где же хваленое разбиение блоков? :(

Re: На то и смайлики

[rssh.livejournal.com]

Кстати есть еще sleepycat. Berkly DB, если кто помнит.

[lstranger.livejournal.com]

Мне кажется, что задача "в общем виде" не решаема. И полумеры могут только усугубить вероятность ошибок. Хотя я могу и ошибаться, поскольку размышления умозрительные, а не практический эксперимент.

[smartcoder.livejournal.com]

Доброе время суток!
Не подскажете, как сделать, чтобы почтовые сервера могли проверять у exim подлинность пользователя? А то когда они ломятся "напрямую", то их отрубают по Autorization Required :(