jack2 icon indicating copy to clipboard operation
jack2 copied to clipboard

Metadata database does not honour the group set by `JACK_PROMISCUOUS_SERVER`

Open gnif opened this issue 3 years ago • 4 comments

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 and libdb-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.

gnif avatar May 03 '21 12:05 gnif

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.)

catniptwinz avatar Jun 24 '21 02:06 catniptwinz

It is not expected behaviour, this is a bug and needs to be fixed in jack itself.

gnif avatar Jun 24 '21 02:06 gnif

Patches welcome. If you find something that works for this use case, please open a pull request.

falkTX avatar Jun 24 '21 09:06 falkTX

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

catniptwinz avatar Jun 24 '21 15:06 catniptwinz