= Сообщение: 1079 из 5336 ========================================= RU.HUSKY =
От : Pavel Gulchouck 2:463/68 25 May 15 15:11:46
Кому : Alexey Vissarionov 25 May 15 15:11:46
Тема : Messagebase permissions (unixes only): system default, owner: not defin
FGHI : area://RU.HUSKY?msgid=2:463/68+556322dc
На : area://RU.HUSKY?msgid=2:5020/545+55630e08
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.HUSKY?msgid=2:5020/545+556364d5
==============================================================================
Hi Alexey!
25 May 15, Alexey Vissarionov ==> Pavel Gulchouck:
PG>> иметь N копий одних и тех же сообщений в эхе, которую читает N людей
PG>> - не слишком оптимальное решение.
AV> gremlin@hren:~ > du -sh ~/fido/msgbase
AV> 2.1G /home/gremlin/fido/msgbase
AV> Более сотни эх, многие из которых хранятся порядка 10 лет.
PG>> Но вот multiuser в голдеде с BBS уже не связан, но и до ума не
PG>> доведен.
AV> И не надо - накопители дешевеют быстрее.
Да, это сейчас очень распространённый подход - не экономить диск, не экономить память, не экономить сетевой трафик, не экономить CPU - всё ведь дешевеет. Наверное, такой подход оправдан для коммерческого софта - когда зарабатываются деньги, можно просто посчитать или прикинуть, что выгоднее - сделать более эффективно или устранить какие-то баги или повесить ещё пару свистелок. Для opensource такой дилеммы нет, тут важнее, чтобы автору нравилось (исключение - активная конкуренция с коммерческим софтом). Это, конечно, не значит, что в opensource нужно оптимизировать всегда и везде. Но если, например, у одного варианта сложность растёт линейно от количества пользователей, а у другого квадратично, то этим уже не стоит пренебрегать, потому что это не просто "накопители дешевеют быстрее", это масштабируемость и расширение сферы применимости. Например, multiuser msgbase можно использовать на webbbs, а если каждому юзеру нужна собственная почтовая система со своей msgbase, то уже не прокатит.
Да и в случае opensource сравнивать нужно иначе: ресурсы на оптимизацию тратит один программист однократно, а экономят на железе потом все пользователи всё время использования. Поэтому даже незначительная оптимизация может в итоге оказаться выгодной.
PG>>>> Поэтому на практике либо всё делается от одного пользователя
PG>>>> (которому в таком случае и рутовые права не нужны),
AV>>> Это единственный адекватный вариант.
PG>> Я бы сказал, что это (почти) единственный рабочий вариант на
PG>> сегодняшний день. Но полностью адекватным я бы его не назвал -
PG>> локальная доставка эхомейл-бандлов внутри одной системы
AV> А не пофигу ли, внутри одной или между разными?
Внутри одной системы можно иметь общую msgbase, между разными это затруднительно. Разница только в этом.
Ну вот как при раздаче файлэхи через файлбоксы - логичнее файл разложить хардлинками, чем копиями, это сэкономит место. Хотя тоже можно спросить - не пофигу ли, файлбоксы внутри одного раздела или на разных, можно всегда копии раскладывать.
В конце концов, одинаковые для всех ресурсы всегда стараются использовать совместно, будь то общие для всех утилиты или shared libraries или ещё что.
PG>> Мейлеры передерутся за порты, если только рут не разведёт юзеров по
PG>> разным IP (и не прибьёт это разделение в firewall).
AV> Зачем? Полез чужой порт слушать - получи EACCES (или даже EADDRINUSE).
"Кто первый встал, того и тапки"?
PG>> Даже в этом случае для каждого фидошного пользователя лучше завести
PG>> отдельного служебного с фидошной системой.
AV> Можно фидошную систему и в отдельном контейнере держать. У меня это сейчас именно так и выглядит (увы, всего лишь по
AV> причине отсутствия времени на проведение полноразмерной миграции).
PG>> Как минимум, в целях безопасности: я не на 100% доверяю безопасности
PG>> фидошного софта, там хватает потенциально опасных мест,
AV> Да и на реальные дыры всем во многом начхать... вон сколько дураков до сих пор эхотаг версии 1.4 используют.
Тем более.
А что, кстати, в 1.4? В history от 1.9 я ничего про закрытые уязвимости не обнаружил.
PG>> и мне бы не хотелось, чтобы взлом фидошной системы привёл к полному
PG>> доступу ко всем моим файлам включая private keys.
[...]
AV> Тебе мастер-класс по использованию GPG в связке с SSH провести, или сам пару мануалов прочитаешь? :-)
Я говорил о недостатках безопасности решения "всё вместе в домашнем каталоге одного пользователя без рута".
Отдельный контейнер для фидошной системы - это несколько другое решение, конечно, более секьюрное, но оно более трудоёмко для изначального конфигурирования, и требует рутовых прав.
Да и в этом случае настроить, чтобы golded, запущенный через ssh, по хоткею мог подписывать отправляемое сообщение или расшифровывать принятое, не имея локально приватного ключа, и не предоставив злоумышленнику из контейнера возможность подписать или расшифровать сообщение - это нетривиальная задача. Потому что событие "нужно подписать текст" ведь происходит в голдеде, т.е. в контейнере. И если проколупать дырку из контейнера наружу (например, ssh tunnel) с запросами "подписать этот текст моим ключом и вернуть результат", это даст возможность в эту дырку пролезть и злоумышленнику. Это нужно нечто вроде ssh-agent, чтобы из одной конкретной ssh-сессии были доступны gpg-запросы "наружу", а из других нет - стандартного такого решения для gpg мне неизвестно, костылить - непросто и есть риск ошибиться, открыв лишнее.
При разделении голдеда и фидошной системы по разным пользователям таких проблем нет.
PG>> Вот и получается, что пользователь vasya должен иметь доступ к
PG>> msgbase на r/w, а пользователь, от которого работает фидошный
PG>> мейлер/тоссер/трекер не должен иметь доступа к файлам пользователя
PG>> vasya.
AV> vasya@server:~ > ssh vasyaftn@localhost
Это практически то же, что "sudo -u vasyaftn", о котором говорил я. Только sudo эффективнее, т.к. не требует создания сетевых сокетов и криптования внутри localhost.
Но с msgbase 660 без sudo получается ещё удобнее и эффективнее. И без проблем с доступом к своим файликам из голдеда.
Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5
* Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
|
