= Сообщение: 1065 из 5339 ========================================= RU.HUSKY = От : Pavel Gulchouck 2:463/68 25 May 15 08:31:20 Кому : Pavel Gulchouck 25 May 15 08:31:20 Тема : Messagebase permissions (unixes only): system default, owner: not defin FGHI : area://RU.HUSKY?msgid=2:463/68+5562b69d На : area://RU.HUSKY?msgid=2:5005/49.1+556292b0 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.HUSKY?msgid=2:5005/49.1+5562eb79 ============================================================================== Hi Pavel!
24 May 15, Victor Sudakov ==> Pavel Gulchouck:
PG>> Глобальная концепция (как я её понимаю) тут в идеале должна быть PG>> такая. Всё (binkd, hpt) работает от пользователя fido, соответственно, PG>> msgbase принадлежит этому же пользователю, никаких setuid для hpt не PG>> нужно. Базы имеют права доступа 660, группа fido. Почтовый редактор PG>> имеет setgid fido. Таким образом, пользователи имеют доступ к базе PG>> посредством почтового редактора,
VS> Я в целом согласен с этой концепцией, есть только одно но. В случае вновь созданной эхи, lastread (т.е. файлик .jlr) VS> setgid-ный редактор создаст с правами 644 user:fido, а не 660 fido:fido. Придется эту ситуацию отслеживать и права VS> исправлять.
Значит, .jlr должен создавать тоссер одновременно с созданием остальных файликов для этой эхи. Другой вариант - редактору хранить идентификаторы прочитанных, не прочитанных и удалённых сообщений в домашнем каталоге пользователя, у каждого свои.
VS> Ну и если какие-то области хранятся в msg, то .msg-шки будут тоже создаваться редактором как 644 user:fido.
Не обязательно 644, может быть 664 или 660, но user:fido, да. Как минимум до первого сканирования эхи. С одной стороны, в этом нет ничего особенно плохого - ну сможет пользователь руками изменить своё созданное сообщение, ну и что? С другой - msg действительно не очень подходит для такой технологии.
PG>> Почему в данном случае setgid предпочтительнее, чем setuid? Потому PG>> что, во-первых, это msgbase может иметь права 660, а другие фидошные PG>> файлы - 640 или 600, чтобы даже в случае получения шелла через PG>> почтовый редактор пользователь не мог порушить ноду. Во-вторых, PG>> сохраняя uid, чуть проще и надёжнее аутентифицировать пользователя.
PG>> Но это всё в идеале, а на деле golded никакого разделения прав не PG>> делает, и один пользователь может легко удалить все сообщения в эхе, в PG>> т.ч. не прочитанные другими пользователями. Поэтому на практике либо PG>> всё делается от одного пользователя (которому в таком случае и рутовые PG>> права не нужны), либо делается один "читающий" пользователь и один PG>> служебный (так сделано у меня, например - тогда вместо setgid можно PG>> прямо внести пользователя в группу fido), либо между людьми должны PG>> быть договорённости не удалять сообщения и взаимное доверие.
VS> Или как вариант у каждого свой поинтовый адрес и своя база.
Да, это по сути и есть вариант "всё делается от одного пользователя без рута".
Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5 * Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
