Access to configfs in container

I saw that configs support recently landed but I seem unable to get access to it from my container, am I missing something or is it not possible ?

# snap refresh --channel=latest/edge lxd
lxd (edge) git-2bdd28e from Canonical✓ refreshed
# lxc stop juju-698b11-1-lxd-0
# lxc start juju-698b11-1-lxd-0
# lxc config edit juju-698b11-1-lxd-0
# lxc config device show juju-698b11-1-lxd-0
eth0:
  hwaddr: 00:16:3e:2e:e8:68
  mtu: "9000"
  name: eth0
  nictype: bridged
  parent: br-bond0
  type: nic
sys-kernel-config:
  path: /sys/kernel/config/
  source: /sys/kernel/config/
  type: disk
# lxc config edit juju-698b11-1-lxd-0
# lxc config get juju-698b11-1-lxd-0 security.privileged
true
# ls -ld /sys/kernel/config/*
drwxr-xr-x 4 root root 0 Apr  9 07:37 /sys/kernel/config/pci_ep
drwxr-xr-x 3 root root 0 Apr  9 11:09 /sys/kernel/config/target
# lxc exec juju-698b11-1-lxd-0 -- ls -l /sys/kernel/config/*
ls: cannot access '/sys/kernel/config/pci_ep': No such file or directory
ls: cannot access '/sys/kernel/config/target': No such file or directory

configfs was only added to make systemd happy, we don’t actually allow access to it inside the container as it’s an attack vector.

I suspect it’s also a bit of a magic filesystem, at least based on the behavior you’re showing. It’s acting like one of those filesystem which auto-mounts children path on access but then doesn’t work because of namespacing.

In any case, our intent was not to make it accessible in the container, just to make a mount visible such that systemd would shut up about it :slight_smile:
We do the same with some others like debugfs.

I see, thank you for the clarification.