0

I'm trying to set up opendkim with Postfix (on CentOS).

Having copied my known good private key into place, I'm seeing this:

Nov 16 12:54:26 [host.domain] setroubleshoot[10093]: SELinux is preventing opendkim from open access on the file /etc/opendkim/keys/mykey.private. For complete SELinux messages run: sealert -l 8de37e21-88ab-46af-9927-e6040f6bfc97
Nov 16 12:54:26 [host.domain] platform-python[10093]: SELinux is preventing opendkim from open access on the file /etc/opendkim/keys/mykey.private.

       *****  Plugin restorecon (99.5 confidence) suggests   ************************

       If you want to fix the label.
       /etc/opendkim/keys/mykey.private default label should be etc_t.
       Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
       Do
       # /sbin/restorecon -v /etc/opendkim/keys/mykey.private

       *****  Plugin catchall (1.49 confidence) suggests   **************************

       If you believe that opendkim should be allowed open access on the mykey.private file by default.
       Then you should report this as a bug.
       You can generate a local policy module to allow this access.
       Do
       allow this access for now by executing:
       # ausearch -c 'opendkim' --raw | audit2allow -M my-opendkim
       # semodule -X 300 -i my-opendkim.pp
MikeBeaton
  • 173
  • 1
  • 5

1 Answers1

1

In my case, this was because I moved (mv) my private key file into place, via a user home directory, and it came with the wrong SELinux extended permissions.


EDIT: See comment from @MichaelHampton, it may be sufficient to delete the file and then copy (cp) it into place, instead of (mv).


EDIT: Or see comment from @HermannB, once you have the problem to fix it, it may be sufficient to simply run /sbin/restorecon -v /etc/opendkim/keys/mykey.private.


My original answer:

To fix recreate the key file from new in its directory, for instance:

$ cd
$ sudo mv /etc/opendkim/keys/mykey.private .
$ su
> cd /etc/opendkim
> cat /home/[a.user]/mykey.private > mykey.private
> chown opendkim mykey.private
> chgrp opendkim mykey.private
> chmod 600 mykey.private

It is creating the file from new (i.e. the line with cat) which fixes the basic problem. If you create it from new in the keys directory, it gets the correct SELinux permissions automatically and opendkim can read it. The last three lines give the file the restricted permissions which opendkim also requries.

MikeBeaton
  • 173
  • 1
  • 5
  • 2
    Once you correctly identified the problem as an SELinux issue, following the suggested approach would have been just as easy I recon `/sbin/restorecon -v /etc/opendkim/keys/mykey.private` – Bob Nov 16 '20 at 13:55
  • Yes, I misread(?) that. It _says_ the 'default label should be etc_t. Then you can run restorecon' - which sounds as if you have to fix the label first, then run 'restorecon'. From what you're saying, running `restorecon` does fix the label, in which case yes, that is easier! – MikeBeaton Nov 16 '20 at 14:21
  • 2
    You didn't copy the file, you moved it. If you had copied it, it would have been fine. You could also have used `mv -Z`. – Michael Hampton Nov 16 '20 at 23:35
  • Thanks, Michael! Would that work even if there was no file in place to copy over? – MikeBeaton Nov 18 '20 at 15:19
  • What do you mean "no file"? If there's no file, you can't move or copy it! – Michael Hampton Nov 18 '20 at 15:46
  • Sorry, no pre-existing destination file to overwrite is what I meant! – MikeBeaton Nov 18 '20 at 22:47