Bug 2124671

Description of problem:
After upgrading runc to 1.1.3-2, Linux containers are denied access to tunnel devices.  When runc is downgraded to 1.0.3-2, access to the tunnel devices are restored.  The container was created with "net_admin" and "mknod" capabilities.  Access is also denied when using "all" capabilities.

Version-Release number of selected component (if applicable):
runc-1.1.3-2.module+el8.6.0+15917+093ca6f8.x86_64

How reproducible:
Create a container with the net_admin and mknod capabilities and try to access a tunnel device (Operation not permitted).  Then, downgrade runc and access the tunnel device again.

Steps to Reproduce:

# setenforce 0
# modprobe tun
# dnf -y upgrade runc
# rpm -q runc
runc-1.1.3-2.module+el8.6.0+15917+093ca6f8.x86_64
# podman run -dt --cap-add=net_admin,mknod --name fedora36 fedora:36 /bin/bash
# podman attach fedora36

container# mkdir /dev/net
container# mknod /dev/net/tun c 10 200
container# cat /dev/net/tun
cat: /dev/net/tun: Operation not permitted
container# exit

# dnf -y downgrade runc
# rpm -q runc
runc-1.0.3-2.module+el8.6.0+14877+f643d2d6.x86_64
# podman start fedora36
# podman attach fedora36

container# mkdir /dev/net
container# mknod /dev/net/tun c 10 200
container# cat /dev/net/tun 
cat: /dev/net/tun: File descriptor in bad state
container# exit

Actual results:
Access to tunnel results in "Operation not permitted".

Expected results:
Access to tunnel results in "Success".

Additional info:
Thus problem was observed in a container which uses OpenVPN.  The above reproduction was simplified not to use OpenVPN.  The "File descriptor in bad state" error is likely because there is nothing else attached to the tunnel device.