graphic: 0.600
virtual: 0.599
architecture: 0.559
device: 0.535
hypervisor: 0.518
ppc: 0.473
network: 0.447
mistranslation: 0.446
semantic: 0.425
performance: 0.407
permissions: 0.374
PID: 0.364
user-level: 0.363
risc-v: 0.335
kernel: 0.329
vnc: 0.318
socket: 0.298
boot: 0.294
files: 0.279
register: 0.273
TCG: 0.264
VMM: 0.251
x86: 0.248
KVM: 0.247
i386: 0.230
peripherals: 0.177
arm: 0.165
assembly: 0.156
debug: 0.154

nested 9p filesystem with security_model=mapped-xattr

I do not know whether this is a bug or a feature request, but on a 9p virtfs with security_model=mapped-xattr, access to extended attributes starting with "user.virtfs" coming from the guest seem to be silently ignored. Would it not be more correct to use some sort of "escaping", say map to "user.virtfs.x" on guest to "user.virtfs.virtfs.x" on host or something like that, so that the guest can use arbitrary attributes.

In particular, this would allow nested virtual machines to use nested 9p virtfs with security_model=mapped-xattr.

After looking at the code, it seems that disabling the user.virtfs namespace was the intended behaviour. I have created a patch implementing nesting instead of disabling.

I do not know if this is the right way to do it, but I did some limited testing and it seemed ok.

Interesting approach. But maybe it should be configurable (eg. specify the mapping prefix).


Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?

The status of this issue is unchanged in QEMU, i.e. user.virtfs.* is still filtered out.

If someone wants to see this changed, please use the common way for sending the patch via ML:
https://wiki.qemu.org/Contribute/SubmitAPatch


This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/117