Can't play through BlueALSA without root permissions

[CNK]

Following Juanito's howto and my experience setting it up on RPi OS, I got my bluetooth speaker working via the onboard bluetooth on a Raspberry Pi Zero W (I'll try to do the same on a Zero 2 W later as well). All seems fine now except that unlike on RPi OS I can only play audio if the player program is run as root, otherwise I just get this error and it does nothing:

Code: [Select]

$ aplay 500Hz-1500HzSweep.wav
-- snip lots due to forum error, says "Couldn't get BlueALSA PCM: Rejected send message" in one bit --
aplay: main:830: audio open error: No such device

If I do "sudo aplay 500Hz-1500HzSweep.wav" instead, it plays the audio fine, just like on RPi OS, except there I don't need to run aplay as root.

I don't get any error in the log from the bluealsa daemon program.

In desperation I tried "sudo chmod -R a+rwx /var/lib/bluetooth", but that didn't help. Now I'm out of ideas.

My set-up is as follows:

• tce-load -i alsa bluez-alsa alsa-utils
• sudo modprobe hci_uart
• sudo /usr/local/etc/init.d/bluez start
• sudo bluealsa
• sudo hciattach /dev/ttyAMA0 bcm43xx 921600 noflow
• sudo bluetoothctl
• in bluetoothctl power on
• in bluetoothctl scan on
• in bluetoothctl pair bluetooth speaker address
• in bluetoothctl trust bluetooth speaker address
• in bluetoothctl connect bluetooth speaker address
• in bluetoothctl quit
• aplay 500Hz-1500HzSweep.wav  --  fails with above error
• sudo aplay 500Hz-1500HzSweep.wav  --  plays correctly

/etc/asound.conf is:

Code: [Select]

defaults.bluealsa.service "org.bluealsa"
defaults.bluealsa.device "93:39:04:05:91:A0"
defaults.bluealsa.profile "sco"

pcm.!default {
 type plug
 slave {
 pcm "bluealsa"
 }
}

Profile "sco" is deliberate, I get the same problem using the more common "a2dp".

It might not be all that bad if I have to use root for what I plan to run, but if there's an easy fix then I'd like to know.

[curaga]

This is just a guess, but if the daemon only creates the audio device on the first connect, what happens if you play something short as root and then try to play as user?

[patrikg]

If you check what rights to the dev in the dev directory, to check if you need to add the user (in my example patrik) to that group.
In my arch system i have to add the user to this all groups for get access as the user to devices/files, to take away have to use sudo.

Code: (bash) [Select]

id

uid=1000(patrik) gid=984(users) grupper=984(users),90(network),98(power),108(vboxusers),150(wireshark),985(video),986(uucp),987(storage),991(lp),995(disk),996(audio),998(wheel)

So if you see this example of some samples files in my dev directory, you can see that lots of my groups have access to the device/name.

Code: (bash) [Select]

ls -la /dev

Rights         User   Group      Size    Date         Name
-------------------------------------------------------------
crw-rw----+  1 root   video      81,   0 17 feb 09.10 video0
crw-rw----+  1 root   video      81,   1 17 feb 09.10 video1
crw-rw----+  1 root   video     236,   0 17 feb 09.10 media0
drwxr-x---   3 root   vboxusers       60 17 feb 09.10 vboxusb
crw-rw----   1 root   uucp        4,  64 17 feb 09.10 ttyS0
crw--w----   1 root   tty         4,   0 17 feb 09.10 tty0

And how do i add my self to that specific group you can you this command.

Code: (bash) [Select]

sudo usermod -aG groupname username
And now you can as the user connect to the device via program/app without using sudo!!
But we are not done yet, we have to logout and login again to activate that's the new rights we have.
And also with picore and tinycore you have to make it persistent some way, i think you just need to run

Code: (bash) [Select]

filetool.sh -b
You can also check if your smart, just bring up RPI OS and check whats groups the user belongs to.
And also check the dev files that the groups are.

And my last thing,,, lets see in the /dev/snd

Code: (bash) [Select]

[patrik@hp-arch-new snd]$ ls -al /dev/snd/
totalt 0
drwxr-xr-x   3 root root      260 17 feb 09.10 .
drwxr-xr-x  21 root root     4040 17 feb 09.55 ..
drwxr-xr-x   2 root root       60 17 feb 09.10 by-path
crw-rw----+  1 root audio 116,  9 17 feb 09.10 controlC0
crw-rw----+  1 root audio 116,  7 17 feb 09.10 hwC0D0
crw-rw----+  1 root audio 116,  8 17 feb 09.10 hwC0D2
crw-rw----+  1 root audio 116,  3 17 feb 09.10 pcmC0D0c
crw-rw----+  1 root audio 116,  2 17 feb 10.35 pcmC0D0p
crw-rw----+  1 root audio 116,  4 17 feb 09.10 pcmC0D3p
crw-rw----+  1 root audio 116,  5 17 feb 09.10 pcmC0D7p
crw-rw----+  1 root audio 116,  6 17 feb 09.10 pcmC0D8p
crw-rw----+  1 root audio 116,  1 17 feb 09.10 seq
crw-rw----+  1 root audio 116, 33 17 feb 09.10 timer

There also you can see what groups have access to the sound device/system... yes of course the group audio..
So my first guess you have to add the user to the group audio.

Sorry have to add this...
You should also check the bluetooth device,,, /dev/ttyAMA0 whats group that belongs to..in my arch system ttyS have legacy from serial device with group uucp.

[CNK]

Thanks for the suggestions.

I'm using the default "tc" user. The group of ttyAMA0 is staff:

Code: [Select]

crw-rw----    1 root     staff     204,  64 Jan  1  1970 ttyAMA0

That's the default group for tc, but I added tc to staff and logged in again to make sure, but I get the same problem.

Code: [Select]

$ id
uid=1001(tc) gid=50(staff) groups=50(staff)

This is /etc/group - there aren't many options to choose from:

Code: [Select]

$ cat /etc/group
root:x:0:
lp:x:7:lp
nogroup:x:65534:
staff:x:50:tc

/dev/snd doesn't exist. Maybe that's just for 'real' sound devices? Bluez-ALSA apparantly uses the ALSA "PCM I/O plug-in" according to its README.

Playing sounds still doesn't work as the tc user after running aplay as root. Also "bluealsa-aplay -l" and "bluealsa-aplay -L" fail with error messages containing "BlueALSA PCM list: Rejected send message" too, here's the error message from that:

Code: [Select]

$ bluealsa-aplay -L
bluealsa-aplay: W: Couldn't get BlueALSA PCM list: Rejected send message, 1 matched rules; type="method_call", sender=":1.47" (uid=1001 pid=22249 comm="bluealsa-aplay -L ") interface="org.bluealsa.Manager1" member="GetPCMs" error name="(unset)" requested_reply="0" destination="org.bluealsa" (uid=0 pid=1598 comm="bluealsa ")

The bluealsa-aplay commands also work fine when run as root.

[patrikg]

Sorry for repeating my self:
-- You can also check if your smart, just bring up RPI OS and check whats groups the user belongs to.
-- And also check the /dev files whats groups they belongs to. In the RPI OS.


And if you don't give up, you can use strace utility to track what files have been rejected from the system.
if you make a trace log file with strace with and without sudo,,
And use of diff utility to check what's the differences between this two trace log files.

[CNK]

OK I see now that I do need to add the audio group as you suggested (with "sudo addgroup audio" and "sudo adduser tc audio" because usermod isn't available), but it's not for the /dev file permissions, it's for D-Bus.

From the bluealsa man page:

/etc/dbus-1/system.d/bluealsa.conf
BlueALSA service D-Bus policy file. D-Bus will deny all access to the org.bluealsa service (even to root) unless permission is granted by a policy file. The default file permits only root to own this service, and only members of the audio group to exchange messages with it.

Code: [Select]

$ cat /usr/local/etc/dbus-1/system.d/bluealsa.conf
<!-- This configuration file specifies the required security policies
     for BlueALSA core daemon to work. -->

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <!-- ../system.conf have denied everything, so we just punch some holes -->

  <policy user="root">
    <allow own_prefix="org.bluealsa"/>
    <allow send_destination="org.bluealsa"/>
  </policy>

  <policy group="audio">
    <allow send_destination="org.bluealsa"/>
  </policy>

</busconfig>

I had to reboot and run all the set-up commands again before it would work, but now with tc a member of the audio group things are good! I can aplay without being root. Thanks for the pointer, although of course I should have RTFM in the first place (I actually got distracted reading the README instead)!

/usr/local/etc/dbus-1/system.d/bluealsa.conf is part of the bluez-alsa extension. Maybe the "staff" group should be allowed there by default too? Consider that a suggestion to the maintainer.

Anyway it's working now for me, so thanks again!

[patrikg]

Thank you also for the feedback, and took your time for writing this feedback.

Your answer maybe also answers someone else having the same problem. Thank you.
Sorry for my bad English spelling, but I think you can get what I am telling you.

And i think a better way of doing this is just add a script to the extension tcz file that adds the audio group to the system. And then just point out with printing some message or something else to tell the user have to add itself to the audio group. Or maybe just add tc user from scratch to audio group. I don't know whats the best solution for this linux distrubution.

There are lots of great members in this Linux Distribution that can contribute whats have to happen next to avoid this problem again. 

[Juanito]

Wouldn’t it be better to change alsa to the staff group as it is in x86/x86_64?