Root permission required about bluez-alsa

[arkq]

It seems, that I've got carried away a little bit with my non-root assumption. At first, root was not required, but later I've added permissions related code, which is not compatible with this statement. However, I'm not sure if forcing root user is a good idea.

I'll explain how it works right now, and maybe you will have some thoughts regarding this issue - I'm open to any suggestions.

From the user perspective, connected Bluetooth device should be seen as an extra audio device. All actions (reading, writing, controlling) should be managed with the same permissions as other ALSA devices (e.g. PCI audio card). Therefore, I'm using the "audio" group to manage access permissions. That's why you see "Permission denied" message - user bluealsa is not able to change controller socket group to "audio". Starting daemon with --group audio fixes this issue.

Internally, bluealsa has to register audio profiles in BlueZ, which is done via D-Bus. However, accessing BlueZ interface is controlled via the policy file /etc/dbus-1/system.d/bluetooth.conf (at least on gentoo). Obviously, root has granted access, but bluealsa user has not. I haven't seen this issue before, because my user belongs to the plugdev group, so I'm also able to interact with BlueZ.

So, long story sort. After granting BlueZ access to user bluealsa:

# cat /etc/dbus-1/system.d/bluetooth.conf
...
<policy user="bluealsa">
  <allow send_destination="org.bluez"/>
</policy>
...

and changing daemon group to audio:

start-stop-daemon --start --exec /usr/bin/bluealsa --user bluealsa:audio

I'm now able to run bluealsa as a non-root user and any user who belongs to the audio group is able to connect to virtual Bluetooth PCM device.

I've tested this on the current master snapshot, however v1.1.0 should be compatible.

[infirit]

Thanks for reply and explanation, I'll poke at this some more and report how things went 😄

[infirit]

However, accessing BlueZ interface is controlled via the policy file /etc/dbus-1/system.d/bluetooth.conf (at least on gentoo).

I can make bluealsa part of the plugdev group to fix that.

The problem I see now is that bluealsa (any non root user probably) is not allowed create files/dirs in /var/run. And this is where I am getting the permission denied from. When I create the dir manually and change the permission accordingly I can start it with start-stop-daemon.

But then when I try to create the bluealsa dir in /var/run through Portage it complains (rightly so) that I have no business doing things in there. Wouldn't /var/lib/ be a better place to create and tear down these sockets? edit, thought about it and this is not right.

[infirit]

Had a quick look at avahi, they appear to set everything up (pid file, dirs etc) and then drop root privileges.

[arkq]

I've chosen /var/run/ because it points to /run/ (at least on Gentoo and OpenSUSE), which is a tmpfs, so I do not have to worry about cases when bluealsa crashes and there are leftovers in the directory. This directory guarantees, that in the worst case scenario, reboot will do its job (like on Windows™ :D). But to be honest, I don't know if this directory is a right place to keep communication stuff.

bluealsa is not allowed create files/dirs in /var/run

Why not just create this directory within the init script? Before running start-stop-daemon do run:

mkdir -p /var/run/bluealsa
chown bluealsa:audio /var/run/bluealsa

I know this is kinda ugly, however I'm not sure if dropping privileges is necessary. I'm not against the idea of dropping privileges, but bluealse does not require root privileges (in theory). It does not interact with the OS in a destructive way. The only interaction it has, is with D-Bus and filesystem.

Incorporating setreuid in the codebase requires new program argument. Then, if there is --user argument, it is kind of natural to add --group argument. Then (like in e.g. avahi) I might add PID file, which brings the need of adding code for daemonization. And so on, and so on :) I'm not against new features, but new features (imho) should be related to the problem the program is trying to solve. Since, there is start-stop-daemon, it is more UNIX way to let it do its job. What do you think?

[infirit]

Since, there is start-stop-daemon, it is more UNIX way to let it do its job. What do you think?

Yeah, adding all that is a bit much for bluealsa. I submitted my modified ebuild and init script to the gentoo bug tracker [1]. It builds and runs correctly now, creating the directory if needed. Thanks for the help 😄.

[1] https://bugs.gentoo.org/show_bug.cgi?id=592310