message repeated 71 times: [ XXX.com: key data is not secure: /home/user-data is writeable and owned by uid 1000 which is not the executing uid (110) or the superuser]
Any hints?
OpenDKIM is the only program complaining about this. I was planning on ignoring it. The threat model for this project assumes all local users are privileged, so it's not really a problem.
It would be nice to have a solution, as 71 times will soon become 700,000!
Do you have RequireSafeKeys false in /etc/opendkim.conf?
This warning is still there. I checked /etc/opendkim.conf and RequireSafeKeys is set to false.
@JoshData is right. Tested on Debian 7 it works perfectly
Same warning here in 2019, latest stable release. And:
grep RequireSafeKeys /etc/opendkim.conf
RequireSafeKeys false
Same error here almost a month later...
# grep RequireSafeKeys /etc/opendkim.conf
RequireSafeKeys false
Latest release according to the status checks.
Same here. I would like this issue reopened.
Do you just need to change a permission somewhere to make this go away?
I was wondering about simply changing /home/user-data to be owned by opendkim?
zgrep -c "key data is not secure" /var/log/mail.log*
/var/log/mail.log:984
/var/log/mail.log.1:1769
/var/log/mail.log.2.gz:2357
/var/log/mail.log.3.gz:1811
/var/log/mail.log.4.gz:2397
and
grep RequireSafeKeys /etc/opendkim.conf
RequireSafeKeys false
@CholoTook
Making /home/user-data owned by opendkim means you are effectively putting nearly all of your security into the hands of the OpenDKIM project.
Is that good?
On Wed, 3 Jun 2020 at 13:24, Paul notifications@github.com wrote:
@CholoTook https://github.com/CholoTook
Making /home/user-data owned by opendkim means you are effectively
putting nearly all of your security into the hands of the OpenDKIM project.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mail-in-a-box/mailinabox/issues/125#issuecomment-638162607,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANKSZTXJVZXNJCEE3DHO7Q3RUY6IHANCNFSM4ASOBJJA
.
@CholoTook Not at all.
Most helpful comment
Same here. I would like this issue reopened.