On Wed, Jul 29, 2020 at 09:59:01AM +0200, Roman Mohr wrote: > On Tue, Jul 28, 2020 at 3:13 PM Vivek Goyal wrote: > > > On Tue, Jul 28, 2020 at 12:00:20PM +0200, Roman Mohr wrote: > > > On Tue, Jul 28, 2020 at 3:07 AM misono.tomohiro@fujitsu.com < > > > misono.tomohiro@fujitsu.com> wrote: > > > > > > > > Subject: [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print > > an > > > > error > Yes they can run as root. I can tell you what we plan to do with the > containerized virtiofsd: We run it as part of the user-owned pod (a set of > containers). > One of our main goals at the moment is to run VMs in a user-owned pod > without additional privileges. > So that in case the user (VM-creator/owner) enters the pod or something > breaks out of the VM they are just in the unprivileged container sandbox. > As part of that we try to get also rid of running containers in the > user-context with the root user. > > One possible scenario which I could think of as being desirable from a > kubevirt perspective: > We would run the VM in one container and have an unprivileged > virtiofsd container in parallel. > This container already has its own mount namespace and it is not that > critical if something manages to enter this sandbox. > > But we are not as far yet as getting completely rid of root right now in > kubevirt, so if as a temporary step it needs root, the current proposed > changes would still be very useful for us. What is the issue with root in user namespaces? I remember a few years ago it was seen as a major security issue but don't remember if container runtimes were already using user namespaces back then. I guess the goal might be simply to minimize Linux capabilities as much as possible? virtiofsd could nominally run with an arbitrary uid/gid but it still needs the Linux capabilities that allow it to change uid/gid and override file system permission checks just like the root user. Not sure if there is any advantage to running with uid 1000 when you still have these Linux capabilities. Stefan