[Virtio-fs] Ownership of a file shared between guest and host

[Pra.. Dew..]

Hi Vivek,

I was able to map multiple UIDs/GIDs from virtiofsd to outside by doing the following –


  1.  Executed virtiofs as a new user (virtiofs)
  2.  Enabled  --sandbox namespace
  3.  Disabled the call to setup_id_mappings inside virtiofsd sandbox
  4.  Setup a range for UIDs/GIDs in the namespace in /etc/subuid and /etc/subgid
  5.  Wrote the id_map for virtiofs sandbox (new namespace) using newidmap utiity from commandline with root permissions

I had to do 3 (disable the call to setup_id_mappings inside virtiofsd sandbox) since the id_map can be only written once (enforced by the kernel). When we tried to add the mappings in the setup_id_mappings call that did not work since the kernel checks for any mapping outside the namespace and rejects it unless it is coming from a root user.

Will it be useful if we could make a command line parameter that makes he call to setup_id_mappings optional? The assumption would be that the user will make these mappings outside of virtiofsd using newidmap tool.

Thanks
Prashant


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Pra.. Dew..<mailto:linux_learner at outlook.com>
Sent: Tuesday, July 12, 2022 4:14 PM
To: Vivek Goyal<mailto:vgoyal at redhat.com>
Cc: virtio-fs at redhat.com<mailto:virtio-fs at redhat.com>
Subject: Re: [Virtio-fs] Ownership of a file shared between guest and host

Thank you so much!!! We are using the Rust version now. I will try out the suggestions below. Thanks for the guidance.

From: Vivek Goyal <vgoyal at redhat.com>
Sent: Tuesday, July 12, 2022 12:37 PM
To: Pra.. Dew.. <linux_learner at outlook.com>
Cc: virtio-fs at redhat.com <virtio-fs at redhat.com>
Subject: Re: [Virtio-fs] Ownership of a file shared between guest and host

On Fri, Jul 08, 2022 at 08:18:19PM +0000, Pra.. Dew.. wrote:
> We have been able to setup virtiofs between guest and host (QEMU 6.2/Linux 5.15). We run virtiofsd as a non-root user in the host. We did not want to run it as a root user in order to minimize the attack surface. We run it as a virtiofs user. When we create a file in the shared folder, the permission of the file is virtiofs user and virtiofs group. When we read that file from the guest it shows virtiofs user (only the uid) and nobody group. The goal is to restrict the access of the file to a few services in the guest (not give access to all services). We tried to create a group in the guest and tried to move the file in the new group. However chown gives "bad descriptor." Is there a better way of doing this? Any input is really appreciated. Thank you so much!

Hi,

Are you using C version of virtiofsd (from qemu) or rust version of
virtiofsd found here.

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fvirtio-fs%2Fvirtiofsd&data=05%7C01%7C%7C66056c4b61b0405d2a7008da640357c8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637932262768755509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VFeOhTiZfwYU5QK4XNjRx%2F3WqfDyiI60v%2FV1x9UJD%2BU%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fvirtio-fs%2Fvirtiofsd&data=05%7C01%7C%7C3d9cbe944a2b4857787308da645c53a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637932644970283564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8SnXegzp66wvw3Wi%2FXZ8j%2Fw1BzVmeed6Nv6vouQ%2BzWY%3D&reserved=0>

I would recommend using rust version of virtiofsd now and as German
suggested in another email, let unprivileged user launch a user namespace
and run virtiofsd inside that. That should allow you to do arbitrary
uid/gid switching inside guest.

Thanks
Vivek

> _______________________________________________
> Virtio-fs mailing list
> Virtio-fs at redhat.com
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistman.redhat.com%2Fmailman%2Flistinfo%2Fvirtio-fs&data=05%7C01%7C%7C66056c4b61b0405d2a7008da640357c8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637932262768755509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q%2FAbKkN3lnMCLaOo8bO6ZCpjxes%2BJcvTnqY7y3JFFa0%3D&reserved=0<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistman.redhat.com%2Fmailman%2Flistinfo%2Fvirtio-fs&data=05%7C01%7C%7C3d9cbe944a2b4857787308da645c53a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637932644970283564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EeP3iCctKyIXttDv%2BwvtgG3MzMepqXWp0Vu2hmJ%2BlbQ%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20220819/25d31af9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A2F48238F66E49458DEB42C5C515153F.png
Type: image/png
Size: 155 bytes
Desc: A2F48238F66E49458DEB42C5C515153F.png
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20220819/25d31af9/attachment-0001.png>