Add 'bluetooth' group and policy to home-assistant container #68
Comments
|
Any chance you can submit a PR to help get this working? Otherwise I'll get to it when I have time. |
Sure! Let me try! |
|
I've been trying to make it works since the last comment, without luck... I added this to the Dockerfile and used RUN addgroup -S bluetooth --gid 117 \
&& mkdir -p /etc/dbus-1/system.d \
&& echo $'<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" \n\
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> \n\
<busconfig> \n\
<policy group="bluetooth"> \n\
<allow send_destination="org.bluez"/> \n\
</policy> \n\
</busconfig>' > /etc/dbus-1/system.d/bluetooth.conf \
&& chmod 644 /etc/dbus-1/system.d/bluetooth.confBut got the same authentication error The only time I got D-Bus working was running the container as root Will continue to search for a solution |
|
I figured hass would have issues running in rootless mode for some people, you may want to stick with the official upstream image if you cannot figure it out 😢 |
|
I just found a solution for podman rootless FWIW (which also solves issue #76429 ). So- to back up ab it- my problem was dbus was not able to authenticate from a rootless container (podman). Using strace I was able to find a little more detail about where exactly the authentication was failing, and when googling some of what I found there, I came across some comment in the podman issues queue that sometimes the effective UID (euid) may not be matching the actual UID it wanted. In my case, that made sense-- it seemed that the container's UID (0 running as root) was not matching the host's UID (1002 for the user running the container), which was authorized for dbus. They don't match. So what to do? I tried explicitly making the container run as user 1002 with As a throwaway, it mentions:
I tried adding For what it's worth-- this is on a raspberry pi running straight up debian bullseye (not raspbian or raspberryos or whatever it's called) with the built-in bluetooth hw, not a dongle or adapter. Other things to make sure you've done-- I had previously installed and tested it was working on the debian host-- that is, I was able to scan from the host's I also made sure to add the user running the container to the I also added the following to the run command to map the local /run/dbus to the container's Anyway, the device shows up in the UI (with no entitites listed yet, though I can manually pair to a speaker via For more on the above setup, see the bluetooth instructions. Now I can finally also scan from the container, and I see that it is running as uid 1002! Cheers! |
|
@fat-tire I am still wrestling with the same solution, and end up with the pod complaining of being able to write to |
|
Sure. It's been a couple months so I'm not sure about everything still, but here's what I've got. I should mention that the rpi seems VERY slow for playing audio (it stutters) to a bluetooth speaker, which kind of sucks. But I bet for non media usage this would probably be okay. I can detect other types of bluetooth devices from within home assistant within docker (actually podman): Stuff I did to run this (rootless) w/the official home assistant docker image using Podman. Docker is probably near identical, but I think rootless/Podman is a little safer maybe ? Running debian 11 bullseye (not raspiOS) on a rpi 4. Some packages that may be relevant (?) ii dbus 1.12.24-0+deb11u1 arm64 simple interprocess messaging system (daemon and utilities)
ii bluetooth 5.55-3.1+rpt2 all Bluetooth support (metapackage)
ii bluez 5.55-3.1+rpt2 arm64 Bluetooth tools and daemons
ii bluez-firmware 1.2-4+rpt10 all Firmware for Bluetooth devices
ii bluez-obexd 5.55-3.1+rpt2 arm64 bluez obex daemon
ii libbluetooth-dev:arm64 5.55-3.1+rpt2 arm64 Development files for using the BlueZ Linux Bluetooth library
ii libbluetooth3:arm64 5.55-3.1+rpt2 arm64 Library to use the BlueZ Linux Bluetooth stack
ii libspa-0.2-bluetooth:arm64 0.3.19-4 arm64 libraries for the PipeWire multimedia server - bluetooth plugins
ii pi-bluetooth 0.1.19 all Raspberry Pi 3 bluetooth
ii podman 3.0.1+dfsg1-3+deb11u1 arm64 engine to run OCI-based containers in PodsDon't know if this is all needed but it's what I have installed. Also not sure if you're doing sound but I do remember installing Again, ultimately when I got audio playng and it sound SO stuttery I gave up on the pi. On host: $ groups
esphome dialout audio bluetooth rtkit pulse-accessNote this is a regular user (uid/guid=1002 fwiw) and is NOT in the I have the <policy user="pulse">
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.MediaEndpoint1"/>
</policy>
<!-- allow users of bluetooth group to communicate -->
<policy group="bluetooth">
<allow send_destination="org.bluez"/>
</policy>was added there. Don't think that's doing much but it's there . Here's the #!/bin/bash
buildah bud -t home-assistant:latest --format docker And here's the relevant bits of #!/bin/bash
# you can also just replace ${MYUID} with the user id of whatever account is running this.
export MYUID=`id -u`
export XDG_RUNTIME_DIR=/run/user/${MYUID}
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/${MYUID}/bus
export TZ=`cat /etc/timezone`
# remove any existing container
/usr/bin/podman stop $(/usr/bin/podman ps -a -q)
/usr/bin/podman rm $(/usr/bin/podman ps -a -q) --force
/usr/bin/podman --cgroup-manager=cgroupfs run -d \
--name homeassistant \
--restart=unless-stopped \
-e TZ=${TZ} \
-v /home/${USER}/config:/config \
-v /etc/localtime:/etc/localtime:ro \
-v /run/dbus:/run/dbus:ro \
-v /etc/dbus-1:/etc/dbus-1:ro \
-v /dev/bus:/dev/bus:z \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
-v /run/user:/run/user \
-v /run/mpd:/run/mpd \
-e container=podman \
-e DBUS_SESSION_BUS_ADDRESS:${DBUS_SESSION_BUS_ADDRESS} \
-e XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} \
--systemd=true \
--network=host \
--userns=keep-id \
home-assistant:latestFrom Be sure to add the bluetooth integration from the Settings->Integrations menu. (see here and here and here for configurations) When running, I see "Error: you must provide at least one name or id" probably due to one of those lines but I never bothered to debug it since it works. I'm sure it's one of those lines in the Hope this helps. If you do write a blog about it, do post a link! |
|
Hello, thank you so much for sharing this @fat-tire . Super kind of you to make the time to reply! My use case is a bit different to yours in that I simply want to integrate some Xiaomi temperature and humidity sensors which are passive bluetooth LE devices as far as I understand it. I have been trying to pass less privileges to the container than you have been and still keep getting stuck, but am going to go the whole hog and copy all your permissions/parameters wholesale in an effort to save my sanity. Will update with findings! |
|
Hi again @fat-tire I have my sensors working with the bluetooth dongle attached now. The key blocker is that I am running the container on Fedora, with SELinux enabled (as it should be), which was blocking dbus calls. I added what's called a custom SELinux module, and then all my devices started updating super frequently! Have a read from here onwards in case you are curious as to what I had to do: On another note, here's the yaml version of my container configuration which can be run by I then execute this with the specific command of Thank you again for the info you shared. You helped make things work for me! The critical changes I needed to make that I took from your work were The final issue I run into and have to work around is a bug in podman where the volume h3-config is created with the wrong permissions. This is documented here: podman run is not honoring --userns=keep-id --user=1000:1000 settings while creating volumes |
|
Thanks! I'm so happy to hear something I posted was helpful and that you got it going :) One workaround I found useful in fixing volume/mount permission errors is to manually mount them and then set them while logged into the container as root. Should only need to be done once-- in the build script or perhaps just before the The first version I did of this was to do it from the host, but I had hard-coded the volume location and it's probably more "correct" to do it from the "inside" within the container as in this example. |
|
Hey guys. Thanks for the writeup, it was quite helpful. I discovered I needed a third step on a CentOS Stream distro (RHEL 9.3 beta), possibly because selinux policies for containers have been revised. You can generate a custom selinux policy with udica sudo dnf udica podman setools-console git container-selinux# as container user
podman inspect homeassistant > homeassistant.json# as root
udica -j /home/user/homeassistant.json homeassistant
semodule -i homeassistant.cil /usr/share/udica/templates/base_container.cilIt needed a few more permissions than udica detected, so here is what I ended up with: ... at the end here you might be wondering what this means : This refers to the global namespace (outside our Which keeps all needed permissions for both the container and the system related to homeassistant in one module, it still only applies to containers labelled homeassistant of course.
--- homeassistant_org.cil 2023-05-23 19:32:36.515381026 +0200
+++ homeassistant.cil 2023-05-23 19:49:03.549805579 +0200
@@ -1 +1 @@
-(block homeassistant_org
+(block homeassistant
@@ -5,0 +6,9 @@
+ (allow process ephemeral_port_t ( tcp_socket ( name_connect )))
+ (allow process howl_port_t ( udp_socket ( name_bind )))
+ (allow process ssdp_port_t ( udp_socket ( name_bind )))
+ (allow process node_t ( tcp_socket ( node_bind )))
+ (allow process node_t ( udp_socket ( node_bind )))
+ (allow process self ( tcp_socket ( listen )))
+ (allow process system_dbusd_t ( dbus ( send_msg )))
+ (allow process bluetooth_t ( dbus ( send_msg )))
+ (allow process http_port_t ( tcp_socket ( name_connect )))
@@ -21,0 +31 @@
+ (allow process system_dbusd_t ( unix_stream_socket ( connectto )))
@@ -25 +35,2 @@
- (allow process system_dbusd_var_run_t ( sock_file ( getattr open read )))
+ (allow process system_dbusd_var_run_t ( sock_file ( getattr open read write )))
+ (allow .bluetooth_t process (dbus ( send_msg )))Then you can run container as such with the custom type: I removed as it wasn't needed from my experience, maybe you can elaborate why these were included @fat-tire ? |
|
@dezza thanks, this is finally what let me get bluetooth working. I had to add a few more permissions for other integreations that needed network connectivity though, ended up with: I actually had to translate audit2allow rules for the new ones and udica didnt seem to want to run with my NFS and iscsi binds, so made it a few more hurdles to jump through. |
Latest versions of home-assistant has support for Bluetooth using BlueZ and DBus.
BlueZ is already installed in the image but mounting dbus to the container shows a privilege error on home-assistant logs, by default DBus only allows root user to communicate with the socket.
This is the default config file running
cat /usr/share/dbus-1/system.d/bluetooth.confinside the home-assistant podLooking at the file in my laptop, there's an extra piece that is missing inside the container
Adding that group to the user kah (568) or maybe just creating it, making it optional to use with
supplementalGroupsand adding the policy to the dbus config will allow the use of Bluetooth adapters without rootThe text was updated successfully, but these errors were encountered: