Сохранение вложений отрабатывает нормально (включая следование SGID), но при сохранении самого письма вне зависимости от umask нет прав у группы и других на его чтение. $ ls -l some_file -rw------- 1 lav uucp ... $ rpmqf kmail kdepim-kmail-3.5.0-alt1
reconfirmed for $ rpmqf kmail kdepim-kmail-3.5.5-alt2
Это не ошибка, а задумано авторами kmail Вот участок кода из: kdepim-3.5.7/kmail/kmcommands.cpp KMCommand::Result KMSaveMsgCommand::execute() { mJob = KIO::put( mUrl, S_IRUSR|S_IWUSR, false, false ); Тут можно предложить: 1. закоментировать эту строку чтоб работали установки umask (для этого должны быть очень весомые аргументы) 2. ввести опцию чтоб пользователь мог сам в своем ~/.kde/share/config/kmailrc указать параметр (true/false) (но по умолчанию всеравно оставить false)
(In reply to comment #2) > Это не ошибка, а задумано авторами kmail Ну почему, они вполне могли ошибочно задумать. В конце концов любая ошибка программы реализована в коде :) > > Вот участок кода из: kdepim-3.5.7/kmail/kmcommands.cpp > > KMCommand::Result KMSaveMsgCommand::execute() > { > mJob = KIO::put( mUrl, S_IRUSR|S_IWUSR, false, false ); > > Тут можно предложить: > > 1. закоментировать эту строку чтоб работали установки umask (для этого должны > быть очень весомые аргументы) Лучше предложите весомые аргументы не использовать umask. > > 2. ввести опцию чтоб пользователь мог сам в своем ~/.kde/share/config/kmailrc > указать параметр (true/false) (но по умолчанию всеравно оставить false) Я думаю, умолчание по правам создания должно задаваться в одном месте, и это место - umask.
Я в новом KMail уже видел такое исправление, надо найти и сделать сдесь тоже в зависимости от того же параметра в настройках
(In reply to comment #3) > Лучше предложите весомые аргументы не использовать umask. Я не знаю, зачем. Но абсолютно точно это неспроста. В другом месте в KMail похожее исправили, добавив опцию для старого поведения, отключенную по умолчанию.
А в остальных 2-х местах в этом файле не осилили :-(
kdepim-kmail-3.5.7-alt2
