Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
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!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
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#43681 - [minidlna]: .service file needs to be improved
Attached to Project:
Community Packages
Opened by Tobias Hunger (hunger) - Monday, 02 February 2015, 21:08 GMT
Last edited by Sergej Pupykin (sergej) - Thursday, 26 February 2015, 15:08 GMT
Opened by Tobias Hunger (hunger) - Monday, 02 February 2015, 21:08 GMT
Last edited by Sergej Pupykin (sergej) - Thursday, 26 February 2015, 15:08 GMT
|
DetailsDescription:
The minidlna.service file is introduced by the arch packaging and seems suboptimal to me. I suggest starting the daemon in the following way (untested as I run this in a docker container;-): User=nobody Group=nobody ExecStart=/usr/bin/minidlnad -S This will make the output available in the journal and will allow systemd to monitor the lifecycle of the process more reliably. The following settings would IMHO make a lot of sense, too, to make sure that this daemon can not be exploited: ProtectSystem=full This will make /usr and /etc available to the process in a read-only state only. ProtectHome=on This will make /home unavailable. That should be fine for the global process and admins can easily override this if they do not want this. PrivateDevices=on This will make the real hardware devices inaccessible. This daemon has no need to mess with /dev/sda, ever. NoNewPrivileges=on Will stop the process from running suid binaries or aquire additional privileges in any other way. Additional info: * minidlna 1.1.4-3 |
This task depends upon