Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#73496 - [murmur] >= 1.4.230-1 needs integration with certbot

Attached to Project: Community Packages
Opened by Christoph (cobzcs) - Tuesday, 25 January 2022, 10:33 GMT
Last edited by David Runge (dvzrv) - Tuesday, 25 January 2022, 11:28 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Sven-Hendrik Haase (Svenstaro)
David Runge (dvzrv)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No



Previously murmur was started with root privileges to read certificates and drops privileges afterwards (uname=murmur) option. Now (since 1.4.230-1) murmur is directly started as murmur user (murmur.service file). Certificates could not be loaded anymore.

Additional info:

There are three options in murmur.service which prevent the privilege drop:



murmurd[1741]: <X>2022-01-25 10:36:39.768 SSL: OpenSSL version is 'OpenSSL 1.1.1m 14 Dec 2021'
murmurd[1741]: <W>2022-01-25 10:36:39.768 Initializing settings from /etc/murmur.ini (basepath /etc)
murmurd[1741]: <C>2022-01-25 10:36:39.768 MetaParams: Failed to read /etc/letsencrypt/live/******/cert.pem
murmurd[1741]: <F>2022-01-25 10:36:39.768 MetaParams: Failed to load SSL settings. See previous errors.
This task depends upon

Comment by David Runge (dvzrv) - Tuesday, 25 January 2022, 11:27 GMT
@cobzcs: Thanks for the ticket.

The title is not really correct, as now privileges do not have to be dropped anymore. The murmurd executable is not executed as root but as the murmur user now, whereas before it was run as root and then dropped privileges itself to the murmur user.

The implication of the previous behavior are, that murmurd has access to *all* certificates and *all files* (also by different groups) below /etc. This is now not the case anymore and from a security perspective the much more desirable outcome.

What is missing currently is to define where murmur is retrieving its certificates from (e.g. below /etc/murmur).
Please have a look at --deploy-hooks on how to do this:

I will keep this ticket open as grounds for discussion for a default location and a potential move of the configuration file (/etc/murmur.ini) to a namespaced location (e.g. /etc/murmur/murmur.ini).
Comment by Christoph (cobzcs) - Tuesday, 25 January 2022, 15:41 GMT
@dvzrc: Your arguments are reasonable, thanks.

In this context I came across this conversation:


Solution 1: Copy your certs into a folder which murmur has access to (best via deploy-hooks you mentioned before). For this, a namespace like /etc/murmur/ would be convenient, imho.
Solution 2: Use file ACLs (setfacl) to allow the murmur user to read the certificates explicitly. This only works if your FS supports ACLs.

For now I'm using ACLs.
Comment by Adam (twokilohertz) - Friday, 28 January 2022, 14:57 GMT
Stumbled across this post which was very helpful as I was having trouble with this issue.

I decided to go with cobzcs' solution of copying the certificates to another folder which the murmur user has access to.

In my deploy hook for certbot, I have the following:
/usr/bin/certbot renew --standalone --quiet --agree-tos --deploy-hook "/etc/murmur/ && /usr/bin/killall -SIGUSR1 murmurd"

Where is a script I wrote to copy the certificates and set their respective permissions and ownership.
[ ! -d "/etc/murmur/certs" ] && mkdir --parents /etc/murmur/certs
cp --update /etc/letsencrypt/live/*******/*.pem /etc/murmur/certs
chown --recursive murmur:murmur /etc/murmur/certs
chmod -R 740 /etc/murmur/certs