On Mon, Jan 19, 2026 at 11:38:05 -0600, Wesley Hershberger wrote: > On Thu, Jan 15, 2026 at 3:50 AM Peter Krempa <[email protected]> wrote: > > Thanks very much for the review! > > > > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c > > > index 98229d7cf9..96352821d7 100644 > > > --- a/src/qemu/qemu_command.c > > > +++ b/src/qemu/qemu_command.c > > > @@ -8880,9 +8880,18 @@ qemuBuildInterfaceConnect(virDomainObj *vm, > > > > > > for (i = 0; i < tapfdSize; i++) { > > > g_autofree char *name = g_strdup_printf("tapfd-%s%zu", > > > net->info.alias, i); > > > + g_autofree char *procpath = NULL; > > > int fd = tapfd[i]; /* we want to keep the array intact for > > > security labeling*/ > > > > > > netpriv->tapfds = g_slist_prepend(netpriv->tapfds, > > > qemuFDPassDirectNew(name, &fd)); > > > + > > > + /* Include tapfd path in the domstatus XML */ > > > + procpath = g_strdup_printf("/proc/self/fd/%d", tapfd[i]); > > > > So this resolves to /proc/PID_OF_VIRTQEMUD_PROCESS/fd/NNN. virtqemud > > will close the FD as soon as we pass it to qemu and additionally > > virtqemud might restart where the path stored in the status XML (which > > is mainly used to re-load after restart) would point to the old PID. > > Maybe I misunderstood, but this code is almost an exact copy from > AppArmorSetFDLabel, > where it resolves to "/dev/tapXX" (virFileResolveLink ends up in > g_canonicalize_path, > which must call realpath(3)). XX in that path _should_ be the index > from ioctl SIOCGIFINDEX > which IIUC isn't specific to the virtqemud process.
Ah so if this resolves to /dev/tap??? then that information may make sense to be stored. But it definitely is not obvious what happens in the code above so you'll need to comment it and explain what happens. > All that said, it's super gross to use virFileResolveLink here, > especially because > virNetDevMacVLanTapOpen already has the tapname. I'm wondering if it's > feasible to just > pass the tapname through from qemuInterfaceDirectConnect and use Feel free to plumb it through; qemuInterfaceDirectConnect has only one place where it's called so that should be easy. > qemuSecuritySetPathLabel instead of qemuSecuritySetFDLabel for macvtap > devices. > I have basically no experience with SELinux; to your knowledge would > this work for that > driver as I've described it? AFAIU you need to label the specific FD here for selinux to work properly. Since it's being passed to qemu we still need the FD. You could introduce an API which takes both FD and path to label and apparmor would label the latter, but you can't avoid the FD wit selinux.
