Почему мониторинг электронной почты через msmtp (для RAID mdadm) работает через пользователя, но не работает при запуске через sudo?

Я только что настроил массив RAID 1 с использованием mdadm на Debian. Я пытаюсь включить мониторинг электронной почты mdadm с помощью msmtp. Я следую документации msmtp (https://marlam.de/msmtp/msmtp.html#Examples) и хочу сохранить пароль приложения Gmail с помощью secret-tool или gpg.

Оба инструмента работают отдельно:

• Я могу получить пароль приложения с помощью:

secret-tool lookup host smtp.gmail.com service smtp user [username]

или

gpg --no-tty --quiet --decrypt ~/.msmtp-gmail.gpg

• Я также могу успешно отправлять письма, используя:

echo "test email" | msmtp [emailaddess]@gmail.com

Однако, когда я запускаю sudo mdadm --monitor --scan --test -1, я получаю следующий вывод:

• С использованием secret-tool

sendmail: cannot read output of 'secret-tool lookup host smtp.gmail.com service smtp user [username]'

• С использованием gpg

gpg: can't open '/root/.msmtp-gmail.gpg': No such file or directory
gpg: decrypt_message failed: No such file or directory
sendmail: cannot read output of 'gpg --no-tty --quiet --decrypt ~/.msmtp-gmail.gpg'

• С использованием пароля в открытом виде

sudo mdadm --monitor --scan --test -1 работает, когда я сохраняю пароль непосредственно в файле /etc/msmtprc. Однако я хочу этого избежать.

Вопрос

secret-tool, gpg и msmtp все, кажется, работают корректно, когда запускаются пользователем. Проблема, кажется, возникает, потому что mdadm запускается с sudo.

Как я могу обойти эту проблему? Я хотел бы придерживаться лучших практик в отношении разрешений на файлы/безопасности.

В конечном счете, все, что имеет беспрепятственный доступ к каким-то данным, имеет доступ к этим данным.

Шифрование, предоставляемое secret-tool, полезно только потому что данные недоступны, пока вы не войдете в систему (и не используете ваш пароль для входа, чтобы их расшифровать¹) — но если бы они были разблокированы все время для предоставления доступа root, они были бы… разблокированы все время.

¹ это также причина, по которой инструмент не работает, когда запускается от другого пользователя; служба, хранящая расшифрованные данные, работает на уровне пользователя, и mdadm/secret-tool, запущенные от root, просто не знают, что они должны подключиться к хранилищу секретов UID 1001.

То же самое с GPG; вы можете заставить его работать от root, но закрытый ключ придется хранить без пароля, чтобы mdadm мог его использовать, и если зашифрованный файл находится на том же компьютере, что и ключ без пароля, то это тоже самое, что хранить его в открытом тексте.

Есть способы заставить это работать, например, запуск gpg-agent от root, чтобы можно было использовать защищенный паролем ключ, который необходимо разблокировать один раз за загрузку каждый раз при перезагрузке системы — но хотя это хорошо работает для определенных сценариев использования, система мониторинга RAID может не быть одним из них. (Что произойдет, если сервер перезагрузится, и вы просто никогда не разблокируете для него GPG?)

Таким образом, на безголовом сервере относительно нормально хранить учетные данные в открытых текстовых файлах, доступных только root (или другой учетной записи службы). Например, TLS-клиентские или серверные сертификаты обычно находятся в открытых местах, как и ключи Kerberos и закрытые ключи SSH хоста, которые идентифицируют машину.

Хотя частично смягчает риски то, что такие учетные данные обычно не разделяются между многими различными вещами, а принадлежат исключительно этой службе, поэтому можно ограничить их доступ. То есть, вы не должны помещать ваши собстленные данные аккаунта Gmail в /etc, а вместо этого создать отдельную учетную запись электронной почты (любого провайдера) и использовать ее в качестве “отправителя”. Таким образом, вы снижаете последствия утечки этих учетных данных с “ваша вся онлайн-личность под угрозой” до “одноразовый почтовый ящик без чего-либо внутри под угрозой”.