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.
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
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?
> Thus this makes no sense to be stored in status XML.
Would the above change your position on this?
Thanks!
~Wesley
