jack2
jack2 copied to clipboard
Metadata database does not honour the group set by `JACK_PROMISCUOUS_SERVER`
When using Jack2 in a headless configuration with JACK_PROMISCUOUS_SERVER
the Berkely database is created with the default permissions and ownership of the process, in my instance drwxr-x---
root:root
. This breaks the metadata feature for any clients running as promiscuous user.
Environment
- JACK Version: 1.9.17
- Operating System: Debian
-
Installation: Compiled from Debian source package with
--db
andlibdb-dev
installed.
Steps To Reproduce
# export JACK_NO_AUDIO_RESERVATION=1
# export JACK_PROMISCUOUS_SERVER=someuser
# export $(dbus-launch)
# exec /usr/bin/jackd -R -P84 -dalsa -s -dhw:0 -r48000 -p512 -n2 -H -M
Expected vs. actual behavior
/dev/shm/jack_db
and it's contents should be owned by the group specified by JACK_PROMISCUOUS_SERVER
and be writeable by the group, instead it is owned by the user jack was run as (root:root) and is not group writeable.
I'm seeing a similar issue with JACK_PROMISCUOUS_SERVER
in which /dev/shm/jack_db
is owned by the expected user/group but is not group writeable.
Arch ARM, jack2 1.9.17 installed with pacman, JACK_PROMISCUOUS_SERVER=audio
. I'm starting jackd with a systemd service, running as a dedicated system user.
Starting a client (tested with supernova) as another user in the audio group throws cannot open DB environment: Permission denied
, which I'd expect given that ls -lah /dev/shm/jack_db
shows:
drwxr-x--- 2 jack audio 120 Jun 24 02:09 .
drwxrwxrwt 3 root root 180 Jun 24 02:09 ..
-rw-r----- 1 jack audio 296K Jun 24 02:09 __db.001
-rw-r----- 1 jack audio 40K Jun 24 02:09 __db.002
-rw-r----- 1 jack audio 48K Jun 24 02:09 __db.003
-rw-r--r-- 1 jack audio 12K Jun 24 02:09 metadata.db
If I manually add group write permissions after starting jackd (chmod -R g+w /dev/shm/jack_db
), I'm able to start a client with no error message.
Is this expected behavior? If so what can I do to ensure that the database permissions are set correctly?
(edited -- forgot to specify chmod -R
above.)
It is not expected behaviour, this is a bug and needs to be fixed in jack itself.
Patches welcome. If you find something that works for this use case, please open a pull request.
If you find something that works for this use case, please open a pull request.
Thanks. Not a "real" c++ dev and not familiar enough with the jack codebase at this point to know where to look beyond the point at which the error is thrown in common/JackMetadata.cpp. That said, if I think of something, I'll be glad to give it a try and let you know if it works.
In the meantime, for anyone else who experiences this issue, a workaround is to create and enable a second service ordered after the jack service which cleans up db permissions:
[Unit]
Description=Fix jack db permissions
After=<your jack service>
[Service]
Type=oneshot
ExecStart=/usr/bin/chmod -R g+w /dev/shm/jack_db
[Install]
WantedBy=default.target