Podman container device points to wrong real device file

[toffee]

Probably this issue can be reproduced only if you have more USB devices on your system (I have 4).

To exemplify the behavior I will use the vcontrold USB device.

When the podman container vcontrold was created let's assume that symbolic link /dev/ttyVControlD points to /dev/ttyUSB3.

Using the podman container inspect I can see the command used to create the container:

 "CreateCommand": [
                    "podman",
                    "container",
                    "create",
                    "--name",
                    "vcontrold",
                    "--security-opt",
                    "label=disable",
                    "--cgroups=split",
                    "--log-driver",
                    "journald",
                    "--log-opt",
                    "tag=vcontrold",
                    "--hostname",
                    "vcontrold",
                    "--network",
                    "isolated",
                    "--ip",
                    "172.16.0.230",
                    "--expose",
                    "3002",
                    "--device",
                    "/dev/ttyVControlD:/dev/ttyVControlD:rwm",
                    "--env",
                    "TZ=Europe/Bucharest",
                    "--volume",
                    "/smartserver/etc/vcontrold/:/etc/vcontrold:ro",
                    "--volume",
                    "/smartserver/var/log/vcontrold/:/smartserver/var/log/vcontrold",
                    "custom_vcontrold:3.20.3-v0.98.12"
               ],

and also the devices used:

 "Devices": [
                    {
                         "PathOnHost": "/dev/ttyUSB3",
                         "PathInContainer": "/dev/ttyVControlD",
                         "CgroupPermissions": ""
                    }
               ],

As you can see, even if at creation time the symbolic link was used --device "/dev/ttyVControlD:/dev/ttyVControlD:rwm" seems that the container is using the real device file PathOnHost: /dev/ttyUSB3

The problem appear after a reboot when it's possible that real device file to be something else (like bellow - ttyUSB2):

ls -la /dev/ttyVControlD
lrwxrwxrwx 1 root root 7 Sep 26 21:13 /dev/ttyVControlD -> ttyUSB2

No error and container start, because ttyUSB3 exist in system but now it's totally other device.

With docker this behavior wasn't noticed, so I guess it has something to do with podman (and/or his configuration) .

Do you know this can be fixed (eg. container to use the symbolic link for PathOnHost)?

[toffee]

From the podman docs I read that this is normal: "Note: if host-device is a symbolic link then it is resolved first."

But then, what's the benefit of symlink!?

[HolgerHees]

I agree, makes no sense. Maybe or hopefully it will be fixed sometimes in podman.

We could mount the whole /dev on thees containers until their is a better solution. Not so secure, but just for a few containers.

I created also a bug report in podman to see, what the recommended way is and if we can expect a better solution soon.

containers/podman#24093

[rhatdan]

What does the docker inspect look like?

[HolgerHees]

on my host I have

lrwxrwxrwx 1 root root 12 28. Sep 17:14 /dev/ttyMyTestDevice -> /dev/ttyUSB0

container is created with

docker create -i -t -v /dev/ttyMyTestDevice:/dev/ttyMyTestDevice --name test alpine

inside the container I have

/ # ls -al /dev/
total 0
drwxr-xr-x    5 root     root           380 Sep 28 15:15 .
drwxr-xr-x    1 root     root           134 Sep 28 15:15 ..
crw--w----    1 root     tty       136,   0 Sep 28 15:15 console
lrwxrwxrwx    1 root     root            11 Sep 28 15:15 core -> /proc/kcore
lrwxrwxrwx    1 root     root            13 Sep 28 15:15 fd -> /proc/self/fd
crw-rw-rw-    1 root     root        1,   7 Sep 28 15:15 full
drwxrwxrwt    2 root     root            40 Sep 28 15:15 mqueue
crw-rw-rw-    1 root     root        1,   3 Sep 28 15:15 null
lrwxrwxrwx    1 root     root             8 Sep 28 15:15 ptmx -> pts/ptmx
drwxr-xr-x    2 root     root             0 Sep 28 15:15 pts
crw-rw-rw-    1 root     root        1,   8 Sep 28 15:15 random
drwxrwxrwt    2 root     root            40 Sep 28 15:15 shm
lrwxrwxrwx    1 root     root            15 Sep 28 15:15 stderr -> /proc/self/fd/2
lrwxrwxrwx    1 root     root            15 Sep 28 15:15 stdin -> /proc/self/fd/0
lrwxrwxrwx    1 root     root            15 Sep 28 15:15 stdout -> /proc/self/fd/1
crw-rw-rw-    1 root     root        5,   0 Sep 28 15:15 tty
crw-rw----    1 root     490       188,   0 Sep 28 15:14 ttyMyTestDevice
crw-rw-rw-    1 root     root        1,   9 Sep 28 15:15 urandom
crw-rw-rw-    1 root     root        1,   5 Sep 28 15:15 zero

and the related part from docker inspect is

        "Mounts": [
            {
                "Type": "bind",
                "Source": "/dev/ttyMyTestDevice",
                "Destination": "/dev/ttyMyTestDevice",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],

[HolgerHees]

@toffee as a temporary workaround I mounted the whole /dev path in openhab and vcontrold containers.

82fadc2

I will revert this security gap when podman is able to handle udev rule based devices correctly.

[HolgerHees]

What does the docker inspect look like?

@rhatdan do you need any additional information?