supervisor: add-on with "devices:" config entry does not allow to access device nodes anymore

Describe the issue you are experiencing

Since the logic for the devices: entry in the config.json of add-on has changed some supervisor versions ago, I am not able to properly access certain device nodes in /dev even thought these device nodes are perfectly defined in the corresponding config.json of the developed test add-on (see https://github.com/jens-maus/ha-addon-raspmatic/blob/main/home-assistant-addon-strict/config.json#L21-L32)

What is the used version of the Supervisor?

supervisor-2021.03.04

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

What is the version of your installed operating system?

6.0dev

What version of Home Assistant Core is installed?

core-2021.3.1

Steps to reproduce the issue

1. Install latest HAos
2. Use the following test Addon-Shop URL: https://github.com/jens-maus/ha-addon-raspmatic
3. Install the RaspberryMatic CCU (strict) add-on listed
4. Start the add-on, then exec a shell within the started add-on container (using docker exec -it ...)
5. execute cat /dev/zram0 and see that it returns

   root@339c13ac-raspberrymatic-strict:~# cat /dev/zram0
   cat: can't open '/dev/zram0': Operation not permitted
   

6. Install the other test add-on RaspberryMatic CCU from the same shop
7. Start it with protected mode disabled and see that the same command returns no permission error anymore:

   root@339c13ac-raspberrymatic:~# cat /dev/zram0
   /ïcXiÅEϤⓌhassos-zramswapSWAPSPACE2
   

8. Note, that the only difference between these two test add-ons is, that the config.json of the “strict” add-on version is, that full_access is not set to true and the devices: entry is used and defines /dev/zram0 as a valid access device, thought the strict add-on is still not able to access the device properly.

Anything in the Supervisor logs that might be useful for us?

The only logout I see when starting the strict add-on is:

21-03-05 12:37:13 INFO (SyncWorker_1) [supervisor.docker.addon] Starting Docker add-on ghcr.io/jens-maus/raspberrymatic with version 3.57.4.20210303-802244b
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/002/001
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/002/002
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD serial hardware /dev/input/event3 - /dev/input/by-id/usb-VMware_VMware_Virtual_USB_Mouse-event-mouse
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/002/003
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD audio hardware - /dev/snd/hwC0D0
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD audio hardware - /dev/snd/pcmC0D0c
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD audio hardware - /dev/snd/pcmC0D0p
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD audio hardware - /dev/snd/controlC0
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/001/001
21-03-05 12:37:15 INFO (MainThread) [supervisor.host.sound] Updating PulseAudio information
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD audio hardware - /dev/snd/seq
21-03-05 12:37:15 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD audio hardware - /dev/snd/timer

See, that I didn’t see any further output that might be helpful in seeing if the supervisor provides enough access to the add-on to be able to access the device nodes it requests access for using the devices: section in config.json. In addition, I couldn’t even spot something in the docker inspect output of the container that shows up access assignment for the configured device nodes.

As outlined, in some previous versions a similar add-on config.json without full_access and enough privileged capabilities setting perfectly allowed to access all defined device nodes from the previous devices: config setting. However, after the change (and potentially also some other additional changes) this behaviour somehow broke and now I always have to start the add-on in privileged/non-protected mode to see it accessing the device nodes it requires.