Should udev use `systemd-tmpfiles --create` in chroot environment?

Recently I'm working on a project building bootable Ubuntu images in containers with chroot. To make grub able to discover the "loop" device, I mounted host's /dev into container, and then in container bind mount it to chroot rootfs:

```
mount --rbind /dev "$ROOT/dev"

# and then debootstrap, install packages, etc.
```

However, I noticed that I can no longer use /dev/kvm as normal user in my host. After some debugging I found that host's /dev/kvm ownership is messed up: the group owner is 109 instead of "kvm" in my host. Although I can easily use chown to change that, every time my script starts, /dev/kvm's group owner gets changed.

So guess that I have to dig up what's happening. In udev.postinst, it has a function to check whether it is in chroot:

```sh
chrooted() {
  if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ];
  then
    # the devicenumber/inode pair of / is the same as that of /sbin/init's
    # root, so we're *not* in a chroot and hence return false.
    return 1
  fi
  echo "A chroot environment has been detected, udev not started."
  return 0
}
```

Seems nothing wrong with that, and then find that when it's configuring, it will use systemd-tmpfiles in systems will systemd installed:

```sh
# Automatically added by dh_installtmpfiles/13.6ubuntu1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
 # In case this system is running systemd, we need to ensure that all
 # necessary tmpfiles (if any) are created before starting.
 if [ -z "${DPKG_ROOT:-}" ] && [ -d /run/systemd/system ] ; then
  systemd-tmpfiles --create static-nodes-permissions.conf >/dev/null || true
 fi
fi
# End automatically added section
```

The static-nodes-permissions.conf sets permission of /dev/kvm, and other dev files:

```sh
# cat /usr/lib/tmpfiles.d/static-nodes-permissions.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.

# This file adds permissions on top of static-nodes.conf generated by
# kmod-static-nodes.service. Rules specified here should match the
# permissions specified for udev in 50-udev-default.rules.

z /dev/snd/seq 0660 - audio -
z /dev/snd/timer 0660 - audio -
z /dev/loop-control 0660 - disk -
z /dev/net/tun 0666 - - -
z /dev/fuse 0666 - - -
z /dev/kvm 0660 - kvm -
z /dev/vhost-net 0660 - kvm -
z /dev/vhost-vsock 0660 - kvm -
```

And the semantics of `--create` in `systemd-tmpfiles` is not just put that config into tmpfiles.d. It actually sets ownership and permission:

> --create
>
> If this option is passed, all files and directories marked with f, F, w, d, D, v, p, L, c, b, m in the configuration files are
>
> created or written to. Files and directories marked with z, Z, t, T, a, and A have their ownership, access mode and security
>
> labels set.

Guess that explains what happened to my host's /dev. Although I could defer bind mounting /dev until `grub-install`, I'm still very curious about this issue. I'm not sure whether this behavior is intentional (users should be aware of what udev is doing and get very careful when they're mounting their /dev), or any other workarounds can be implemented that, when in chroot environment, just put configuration file inside tmpfiles.d, and don't change file permission and ownership (I can't find an option like this in systemd-tmpfiles manual).

Thanks!