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
signature.asc
Description: PGP signature
_______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
