[Qemu-devel] [Bug 1500265] [NEW] nested 9p filesystem with security_model=mapped-xattr

[Qemu-devel] [Bug 1500265] [NEW] nested 9p filesystem with security_model=mapped-xattr

[Daniel Haid]

Public bug reported:

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.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1500265

Title:
  nested 9p filesystem with security_model=mapped-xattr

Status in QEMU:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1500265/+subscriptions

[Qemu-devel] [Bug 1500265] Re: nested 9p filesystem with security_model=mapped-xattr

[Daniel Haid]

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.

** Patch added: "nested-virtfs-xattr.patch"
   https://bugs.launchpad.net/qemu/+bug/1500265/+attachment/4476979/+files/nested-virtfs-xattr.patch

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1500265

Title:
  nested 9p filesystem with security_model=mapped-xattr

Status in QEMU:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1500265/+subscriptions

[Qemu-devel] [Bug 1500265] Re: nested 9p filesystem with security_model=mapped-xattr

[Enrico Weigelt, metux IT consult]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1500265

Title:
  nested 9p filesystem with security_model=mapped-xattr

Status in QEMU:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1500265/+subscriptions

[Bug 1500265] Re: nested 9p filesystem with security_model=mapped-xattr

[Thomas Huth]

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

** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1500265

Title:
  nested 9p filesystem with security_model=mapped-xattr

Status in QEMU:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1500265/+subscriptions

[Bug 1500265] Re: nested 9p filesystem with security_model=mapped-xattr

[Christian Schoenebeck]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1500265

Title:
  nested 9p filesystem with security_model=mapped-xattr

Status in QEMU:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1500265/+subscriptions

[Bug 1500265] Re: nested 9p filesystem with security_model=mapped-xattr

[Thomas Huth]

** Changed in: qemu
       Status: Incomplete => Triaged

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1500265

Title:
  nested 9p filesystem with security_model=mapped-xattr

Status in QEMU:
  Triaged

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1500265/+subscriptions

[Bug 1500265] Re: nested 9p filesystem with security_model=mapped-xattr

[Thomas Huth]

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


** Changed in: qemu
       Status: Triaged => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #117
   https://gitlab.com/qemu-project/qemu/-/issues/117

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1500265

Title:
  nested 9p filesystem with security_model=mapped-xattr

Status in QEMU:
  Expired

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1500265/+subscriptions