[Virtio-fs] [RFC] About non-root virtiofsd(1) process

[Stefan Hajnoczi]

On Fri, Jan 15, 2021 at 12:39:13PM +0530, P J P wrote:
> +-- On Thu, 14 Jan 2021, Stefan Hajnoczi wrote --+
> | On Thu, Jan 14, 2021 at 02:11:28PM +0530, P J P wrote:
> | > Ex. By default offer only read access to guest VM.
> | 
> | That's not useful. Most users require read-write.
> 
> * Agreed. I meant let 'rw' access be user's choice than the default for 
>   virtiofsd(1).

I'm not sure I understand. It's the user's choice to run virtiofsd. And
if they are running it then most of the time they want read-write
access.

Requiring extra syntax for read-write doesn't help. Safe defaults work
well for rarely-used features that can really be disabled most of the
time to improve security. This isn't that case.

> | The fundamental issue is that the server must be able to create, access, and 
> | modify files with arbitrary uids/gids.
> 
> * Why arbitrary uids/gids? Once a directory is shared with a guest, its 
>   uids/gids would stay same, no?

Guest applications may run with different uids/gids. The host has no
control over that.

Imagine booting a guest form a virtio-fs root file system and installing
packages. The guest must be able to control uids/gids for that to work.

There are specific use cases where restrictions are acceptable, but they
have trade-offs (e.g. the file system on the host does not have the same
uid/gids as inside the guest). The current approach supports all guest
applications, whereas other approaches do not. It is possible to add
uid/gid restrictions to tighten security for some use cases (like the
unprivileged virtiofsd that you suggested below with -runas).

> * We also start separate virtiofsd(1) process for each share/guest too. ie.  
>   single virtiofsd(1) daemon is not catering to multiple guests and their
>   respective shared directories, right?

Yes. Each virtio-fs device has a separate virtiofsd process.

> | If you have specific ideas, let's discuss them.
> 
> * One was to have a command line switch similar to 'qemu -runas <user>'
> 
>      $ ./virtiofsd -runas test -o source=...
> 
>   If a user wants to run virtiofsd(1) with non-root privileges, it'll be 
>   handy.

Patches for this are welcome. It can't be used for Kata Containers or
other virtiofsd use cases that where uids/gids matter, but it's a good
choice to share an unprivileged user's directory with the guest.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20210118/38f0e39f/attachment.sig>