Bug 217827 - audio/murmur cant read letsencrypt certs
Summary: audio/murmur cant read letsencrypt certs
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Mark Felder
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-16 08:45 UTC by gspu
Modified: 2018-12-02 19:38 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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.