背景：
我在 debian buster 上运行一个带有 postfix/dovecot 的邮件服务器，如下所示本指南。按照指南所述，我在前端安装了 roundcube。
指南的最后一章讨论了加密，如果你遵循它，你最终会得到基于每个用户的加密（在 dovecot'sh 中，这被称为“文件夹加密”，而不是“全局加密”）。
这是一个简洁的设置，我对一切都很满意，除了一点：
让我烦恼的是：
一旦用户更改密码，管理员就必须登录服务器并更改加密密钥（因为 mail_crypt 插件配置为使用用户的密码..是的）。
这有两个缺点：首先，很明显“有人必须手动登录远程才能执行命令”这一部分，这可能会让不断增长的用户群感到有些烦恼。其次 - 这让我从安全角度感到担忧 - 管理员是否必须知道用户的旧密码和新密码。在我看来，这是不行的。
我的艺术状态：
我很聪明，我在密码插件的基础上构建了一个小插件，该插件将在密码更改时触发。然后它会运行 doveadm 命令来调整加密密钥。
到目前为止，一切都很好...
显然，roundcube（以及插件）与 dovecot 运行的用户不同。如果不进行进一步配置，这将导致权限被拒绝错误（事实上，错误消息更加隐晦，但您明白我的意思。）
因此我所做的是将 dovecot user_query 改为使用 web 用户（而不是邮件用户），并且在此步骤中也改变了 Maildirs 的所有权。
-> 该插件运行良好，因为 Web 用户现在可以完全访问 Maildir。
问题/我的问题：
由于所有邮件现在都归运行 Web 服务器的同一个用户所有，我睡不着觉，因为我知道错误输入字段中的错误或错误字符可能会导致……好吧……错误的结果。（尽管邮件已加密，没有人——甚至 root 都无法阅读它们，但 Web 用户仍可能删除这些文件……）。
我会定期备份系统，以防万一。但是出于好奇，你们有没有更好的方法来处理这种情况？我是否可以从运行插件的 Web 用户升级到运行 doveadm 的邮件用户，而无需 Web 用户拥有（希望不是 pwning）Maildir？
提前致谢 - 无论如何，我希望这是提出这个问题的正确 SE 页面，并保持健康！
快乐编码
答案1
看看这里 -https://gist.github.com/yajrendrag/203b0172fee96a8b002a026362d27bf2- 您可以忽略与 postfixadmin 相关的所有内容（我对其进行了修改，使其与 ISPMail 指南（包括加密）配合使用），但请查看指南的“后半部分”，其中专门讨论了加密。但在步骤 7 中，我解决了 roundcube 密码更改情况。我添加了以下内容：
/* added to update crypto password when user changes password */
system ('sudo /usr/bin/doveadm mailbox cryptokey password -u '.escapeshellarg(self::username()).' -n '.escapeshellarg($passwd).' -o '.escapeshellarg($curpass));
在
/usr/share/roundcube/plugins/password/password.php该行后面的私有函数 _save 中case PASSWORD_SUCCESS。
还添加$config['password_confirm_current'] = true;到配置中，/etc/roundcube/plugins/password/config.inc.php因此用户必须输入当前密码才能更改密码。
我猜我可能做了一些类似于你在插件中做的事情……但除此之外，在步骤 9 中，我还添加了
www-data ALL=(root) NOPASSWD: /usr/bin/doveadmwww /etc/sudoers.d/local-data 可以以 root 身份执行 doveadm 而无需密码。你可能认为这太不安全了，但这样，我就不必对文件所有权进行任何更改，而且服务器只属于我，所以我对此没意见。
答案2
我发现这个问题启发：
另一个更好的方法是将 /etc/sudoers.d/myOverrides 更改为：
<user> ALL= (<dummy user>) NOPASSWD:/path/to/chromium-browser这允许运行 /path/to/chromium-browser 而无需提示输入密码。
sudo -u <dummy user> -i /path/to/chromium-browser
我将邮箱所有权从 www-data 转移到 vmail，并按照上述说明进行操作。
我非常确定这种类似 PAM 的解决方案是我能想到的最安全的解决方案，原因有二：A：我们通过将 Web 邮件服务器与实际邮箱分开来最大限度地减少攻击面（不，我并不偏执）B：我们仍然在非特权环境中运行这两个进程（无 root 权限）
欢迎您证明我错了。（实际上，我甚至希望在所有其他情况下完全关闭 sudo。可能吗？...也许）
我将这个问题“开放”给那些花时间让这个问题更全面、更有启发性并获得“最佳答案”标签的人。然而，这对我和其他人来说是一个解决方案:)