|Summary:||audio/murmur cant read letsencrypt certs|
|Product:||Ports & Packages||Reporter:||gspu <netbackup.gs>|
|Component:||Individual Port(s)||Assignee:||Mark Felder <feld>|
|Status:||Closed Not A Bug|
|Severity:||Affects Some People||CC:||arrowd|
Description gspu 2017-03-16 08:45:48 UTC
Murmur is unable to read the certificates from */live/YOURURL/*.pam The solution: Change the user in rc.d/murmur to root, then in the murmur.ini-file uname=murmur and erverything is fine.
Comment 1 Mark Felder 2017-03-16 14:32:59 UTC
What tool are you using to fetch the LetsEncrypt certificates? Couldn't you use the post-hook functionality to change the group ownership of the certificate/key to "murmur" and make sure the files are mode 440 ? This would be trivial with security/dehydrated. I ask this because the requested change would be rather disruptive to existing users.
Comment 2 gspu 2017-03-16 15:26:50 UTC
I use the Certbot (as root) tool from the ports, i also tried to change the permissions from the certs to murmur 440, but no success. Everything else (nginx, tomcat etc) works normal with the root permissions not so murmur. But its funny that startup murmur as root, and let it run as murmur (uname=murmur in the ini-file) works perfectly.
Comment 3 Mark Felder 2017-03-16 15:50:29 UTC
I assume that a directory in the path to the certificate and key files is not allowing non-root users to access it. The other applications and the change you propose likely read the certificate and key before dropping privileges. I will investigate this further. Your feedback on this matter has been greatly appreciated.
Comment 4 gspu 2017-03-16 17:08:58 UTC
Maybe you can change the startup-script to look into murmur.ini, if uname=murmur is set start it with root, otherwise startup as murmur (like now). With this "solution" you would not disrupt others installation, just an idea, don't know if this is "clean". For new installations set uname to murmur Thank you very much for investigate in this case.
Comment 5 gspu 2017-03-16 17:12:19 UTC
Or just inform at the end of installation, that if letsencrypt/certs with root then change this and that. I think its the easy and clean way.
Comment 6 gspu 2017-07-31 12:41:40 UTC
Any news on this?
Comment 7 Gleb Popov 2018-12-02 19:38:57 UTC
(In reply to Mark Felder from comment #3) > The other applications and the change you propose likely read the certificate and key before dropping privileges. You're absolutely right. For example, apache starts httpd as root, reads config and certificate files and then forks with www user, passing the data to them. Same goes for nginx, probably. The problem with murmur can be observed because it doesn't change the user by default. I don't think anything should be done on our (ports) side, it is a purely configuration complexity that user should be able to overcome himself.