Refactor device enumeration for unprivileged containers

[ciandonovan]

There are currently two solutions I'm aware of to run librealsense in a Podman/Docker OCI container.

The first is to run the container with the --privileged flag, giving it access to all the host's devices. But this also disables beneficial security features, and weakens the sandbox boundary.

The second is to use the --device-cgroup-rule "c 81:* rmw" flag to allow access to the USB, but this is still far from ideal as the all USB devices are exposed.

#3849
IntelRealSense/realsense-ros#1104
https://github.com/IntelRealSense/librealsense/blob/master/scripts/Docker/readme.md
https://www.matrix-vision.com/manuals/mvBlueFOX3/UseCases_section_mvBF3_in_docker.html

Ideally it would be possible to pass through to the container only the devices we need with the --device flag, in this case a subset of the /dev/video* devices. This is especially useful for systems with multiple RealSense cameras attached, where one container is setup to handle each camera, and each camera is passed through to each container individually.

However, this doesn't work currently, because in enumerating devices, librealsense naively assumes that the sysfs entries /sys/class/video4linux/video* map directly to their corresponding /dev/video* devices. In most cases this is the correct assumption, but this doesn't hold for unprivileged rootless containers. In these containers, devices passed through must be named explicitly on container creation, and don't necessarily match the same name as on the host. Depending on how many cameras are plugged into the host, a particular device's video node numbers will be different, but they'll still have the same fixed number in the container.

librealsense simply lobs off the /sys/class/video4linux/ part of the path and replaces it with the string /dev/, leading to it trying to access a device not present in the container's mount namespace and failing to discover the camera that's attached.

My pull request modifies this behaviour, introducing a new function std::string get_devname_from_video_path(const std::string& video_path) to perform the task of correctly matching video4linux sysfs entries with their corresponding devfs devices.

This is done by first parsing the sysfs uevent file and extracting the device major and minor number, then searching each file in /dev to see if there's a match. If so, the string of the device name is returned, if not, and empty string is returned and that sysfs entry is ignored.

I've confirmed that this works with and without udev and with the official .

• RealSense ROS v4.51.1
• Running with LibRealSense v2.55.0
• Device Name: Intel RealSense D435I
• Device FW version: 5.13.0.50
• Device Product ID: 0x0B3A

I have not tested with any other Intel RealSense products as I don't have access to any, especially MIPI based ones, would appreciate if someone could test that too.

I also haven't covered any iio:device devices, but from a brief reading of src/linux/backend-hid.cpp it looks like they're accessed exclusively through the devfs and so simply passing them through to the container with the --device flag should suffice. If someone has a test application that makes use of them, or the HID-SENSOR-2000e1.5.auto, I can test to ensure they still work too.

[ciandonovan]

The to the CI build doesn't seem to be working.

Got this email where the subject line says the build failed, but from the body it looks like all the checks passed?

[Nir-Az]

The to the CI build doesn't seem to be working.

Got this email where the subject line says the build failed, but from the body it looks like all the checks passed?

Hi @ciandonovan
Windows build seems to be missing, probably a CI machine error.
We will double check soon.

Thanks for the PR.

[ciandonovan]

Is there anything I can do on my end to help fix that failing check? Unfortunately the link still isn't working so can't see exactly what's wrong.

[Nir-Az]

Is there anything I can do on my end to help fix that failing check? Unfortunately the link still isn't working so can't see exactly what's wrong.

Hi,

Please allow some time, once we can make it we will review this PR, thanks!

[dmipx]

hi @ciandonovan
Thank you for PR.
We review it.
Can you squash all commits?
Thanks.

[ciandonovan]

Hi @dmipx

Will I rebase onto the head of the development branch too? Has been a while and is quite behind in terms of upstream commits by now.

[ciandonovan]

Removed the part affecting the MIPI handling and squashed the remaining commits

[ciandonovan]

I changed all the appropriate LOG_INFO to LOG_ERROR.

I now also always explicitly check the return code of get_devname_from_video_path to avoid TOCTOU issues, and take the appropriate action at that point to either throw an error or ignore if that can be done safely.

[ciandonovan]

Commits squashed and ready for review

[ciandonovan]

Fixed the get_devname_from_video_path() to return false when no devices are found

[dmipx]

LGTM

[Nir-Az]

@ciandonovan Thanks again for this PR.
Since this is a core change in our SDK, we will have to run several internal ci processes.
Please allow us some time to validate before we merge.
Thanks 😀

[dmipx]

@ciandonovan
Hi.
We are moved further with development branch.
Can you rebase your PR on development? This will help us to validate your changes.
Your changes have no conflict.
Thanks.

[dmipx]

Verified.

[Nir-Az]

Close & reopened to trigger CI, last run had a failure, let's see it it's persistent.

[ciandonovan]

LRS_libci_trigger still failing, but the link isn't working so can't check why myself :(

[Nir-Az]

LRS_libci_trigger still failing, but the link isn't working so can't check why myself :(

Yes, this is an internal CI, I will update once I get the results