Phillip Carroll <domainmanager@???> (Mo 22 Aug 2016 18:50:32 CEST):
> On 8/22/2016 3:57 AM, Heiko Schlittermann wrote:
> >Directories 0777? Sounds dangerous. I think, Exim doesn't do extensive
> >checks to ensure system security, but I'd remove the the group/world
> >write bits from the directories.
>
> You are correct, of course. The directory permissions are all actually set
> to 755. I should have written that the paths are all world-readable.
>
> >Try to use
> >
> > sudo -iu <your exim user>
> >
>
> That resulted in: "This account is currently not available."
>
> The help for sudo shows no option -iu on my system. What is that supposed to
> do? The following command displays the pem:
sudo -i -u <your exim user>
should be the same as `sudo -iu <your exim user>`, but because of `-i`
it starts the exim user's login shell, probably set to something that
issues the above message.
sudo -su <your exim user>
should then do the trick
> sudo -u exim cat /path/to/cert.pem
>
> I don't think the issue has to with the exim user per se. It appears that
> some library function is asking for more permission than it needs. (fopen ?)
> Apache has no problem because it reads the cert as root.
fopen can ask for 'r', 'rw', … and I'm quite sure that it doesn't ask
for write permissions on the cert/key files.
> Changing the group of the current fullchain pem file to "mail" resolved the
> issue with the cert. However, the error message then became:
> (SSL_CTX_use_PrivateKey_file file=/path/to/privkey.pem):
> error:0200100D:system library:fopen:Permission denied
>
> Changing the group of the private key file to "mail" then resolved that
> issue. However, that raises the question: Why must the private key be
> readable by exim at all? I have always been under the impression that a
> private key should ALWAYS be readable only by root.
No, the private key needs to be readably by the process that wants to
use it. With the effective permissions at the time of fopen()ing the
key/cert material.
Exim has "dynamic" names for cert/key material, the tls_* options are
subject to expansion. This expansion is delayed as much as possible, to
get as much as possible information for flexible expansion (client IP
address, client helo name, …). This implies that Exim, for safety
reasons already dropped it's privileges.
> I have now restored the group to "root" of the two files, and reverted back
> to the exim-owned cert for STARTTLS usage so that the primary private key of
> the site remains accessible only to root. That seems to me the safest
> scheme.
Some systems use a group 'ssl-cert', add this group as a supplementary
group to all users that need access and then adjust the access to the
private material accordingly (rw-r----- root ssl-cert
private/foo-key.pem).
Another approach is using POSIX ACL to grant access for the exim user to
the private matrial (setfacl(1))
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
