/run/lock/fluidsynth is world-writable
FluidSynth version
>fluidsynth -V
FluidSynth runtime version 2.4.7
Copyright (C) 2000-2025 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of Creative Technology Ltd.
FluidSynth executable version 2.4.7
Sample type=double
Describe the bug
The file "fluidsynth.tmpfiles.in" contains d /run/lock/fluidsynth 0777 root root This makes "/run/lock/fluidsynth" world writeable.
Expected behavior
"/run/lock/fluidsynth" should only be writeable by root.
Steps to reproduce
ls -lad /run/lock/fluidsynth/ drwxrwxrwx. 2 root root 40 18. Okt 08:04 /run/lock/fluidsynth/
Additional context
I would suggest setting d /run/lock/fluidsynth 0755 root root
For Fedora see: https://bugzilla.redhat.com/show_bug.cgi?id=2404360
No my bug. Fluidsynth's CMake build system does not install the tmpfile. It needs to be installed through the RPM spec file. We have set the permissions of this file correctly in our own spec file:
https://github.com/FluidSynth/fluidsynth/blob/67a09a6147697f4c3b958c05db67c81503e04813/contrib/fluidsynth.spec#L101
Pls. reach out to the Fedora package maintainer to fix this.
Sorry I did not explain in a good way. It is not about the permissions of the file itself, but about the content of "fluidsynth.tmpfiles.in": d /run/lock/fluidsynth 0777 root root
With this content the file (directory) "/run/lock/fluidsynth" gets world writeable.
Sorry, my bad. I can't read.
I would suggest setting d /run/lock/fluidsynth 0755 root root
I was digging a bit in the history of that file and I'm afraid it's not that simple. From my understanding, setting the permissions of that file to root only would prevent fluidsynth to be started as unprivileged user daemon, which seems to be the common use-case downstream. Particularly: #1527 and its PR #1528
And here's the reason why we need that lock file: #1491
I'm not a systemd friend and I have no idea how to address this problem. Any help appreciated.
I also do not know about the right way to correct this, but I can ask at fedora devel group.
About #1491: If the first user blocks port 9800, the second user cannot use it. This is true, no matter if this port is blocked by a fluidsynth user service or by some other (handwritten) script/code. The shared resource (~lock) is the (local) port number. But maybe I do not understand this ticket correct.
This is true, no matter if this port is blocked by a fluidsynth user service or by some other (handwritten) script/code.
Right. I was thinking about a "select the next free port" mode. But even then, the user would likely only have one soundcard, so having a lock that avoids multiple fluidsynth's daemons from playing audio on the same device is still reasonable.
I'm on Fedora Rawhide; I wanted to use Fluidsynth but I got a crash.
Starting fluidsynth.service - FluidSynth Daemon... touch: Unable to touch '/run/lock/fluidsynth/fluidsynth.lock': Permission denied fluidsynth.service: Control process exited, code=exited, status=1/FAILURE fluidsynth.service: Failed with result 'exit-code'. Failed to start fluidsynth.service - FluidSynth Daemon.
fluidsynth-2.4.8-1.fc44
Changelog * Thu Oct 16 2025 Christoph Karl <pampelmuse [AT] gmx [DOT] at> - 2.4.8-1
- Update to 2.4.8
- Fix world writeable /run/lock/fluidsynth
I'm on Fedora Rawhide; I wanted to use Fluidsynth but I got a crash.
Starting fluidsynth.service - FluidSynth Daemon... touch: Unable to touch '/run/lock/fluidsynth/fluidsynth.lock': Permission denied fluidsynth.service: Control process exited, code=exited, status=1/FAILURE fluidsynth.service: Failed with result 'exit-code'. Failed to start fluidsynth.service - FluidSynth Daemon.
Right, I will fix this soon. In the meantime you can remove the following lines from "/usr/lib/systemd/user/fluidsynth.service": ExecStartPre=touch /run/lock/fluidsynth/fluidsynth.lock ExecStopPost=rm -f /run/lock/fluidsynth/fluidsynth.lock
Should be fixed in "fluidsynth-2.4.8-2.fc44"
Hi! 👋
I'm packaging this project for Arch Linux.
I have also just applied a similar patch (https://gitlab.archlinux.org/archlinux/packaging/packages/fluidsynth/-/commit/3da0014562337fc32396d30d23d49a59bd2901ee) to not expose the lock dir world-writable.
It would be great to find a different approach here to prevent port collision, as the current approach has negative security implication on the entire system (exposing a /run/ directory world-writable can lead to DoS on a system - https://gitlab.archlinux.org/archlinux/packaging/packages/fluidsynth/-/issues/7).