Comment 12 for bug 2013318

Hi Steve, I can confirm that runc 1.1.4-0ubuntu1~22.04.2 in ubuntu jammy proposed fixes the issue I'm observing.

The testing I done is following:

1) Downloaded the built package from launchpad:

    # wget 'https://launchpad.net/ubuntu/+source/runc/1.1.4-0ubuntu1~22.04.2/+build/25995926/+files/runc_1.1.4-0ubuntu1~22.04.2_amd64.deb'

2) Installed package with apt:

    # apt install ./runc_1.1.4-0ubuntu1~22.04.2_amd64.deb

3) Verified correct version is indeed installed:

    # dpkg -l runc | grep ii
    ii runc 1.1.4-0ubuntu1~22.04.2 amd64 Open Container Project - runtime

4) Run new docker container:

    # docker run -d alpine sleep 10000
    2f2729419a668b9b2182122147b167caca3c551d2af300ac43d46aab67924020

5) Verified systemd configuration using the returned container ID:

    # systemctl cat docker-2f2729419a668b9b2182122147b167caca3c551d2af300ac43d46aab67924020.scope | grep DeviceAllow
    DeviceAllow=
    DeviceAllow=char-pts rwm
    DeviceAllow=/dev/char/10:200 rwm
    DeviceAllow=/dev/char/5:2 rwm
    DeviceAllow=/dev/char/5:1 rwm
    DeviceAllow=/dev/char/5:0 rwm
    DeviceAllow=/dev/char/1:9 rwm
    DeviceAllow=/dev/char/1:8 rwm
    DeviceAllow=/dev/char/1:7 rwm
    DeviceAllow=/dev/char/1:5 rwm
    DeviceAllow=/dev/char/1:3 rwm
    DeviceAllow=char-* m
    DeviceAllow=block-* m

The above is how I expect the configuration should look like. Broken configuration was missing most of the DevieAllow settings.

6) Ran systemctl daemon-reload and afterwards verified that I still can access /dev/null inside the container as usual:

    # docker exec -ti 2f2729419 cat /dev/null

Prior to fix, exec would fail. And even if I kept shell from docker exec prior to daemon-reload, /dev/null inside the container would be inaccessible.

So as far as I can see, the package runc_1.1.4-0ubuntu1~22.04.2_amd64.deb does fix the issue on jammy.

Hope that helps.