On Wed, Jan 20, 2021 at 02:49:52PM +0900, Chirantan Ekbote wrote: > On Tue, Jan 19, 2021 at 11:34 PM P J P <[email protected]> wrote: > > > > +-- On Mon, 18 Jan 2021, Stefan Hajnoczi wrote --+ > > | 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. > > > > * I see; I'll try to better understand how it's done. > > > > * With UID namespaces, I thought virtiofsd(1) would be able to operate files > > with arbitrary uid/gid, even after dropping its root privileges to acquire > > non-root privileges on the host; Because it has 'root' privileges under > > the > > shared directory & UID namespace. > > > > This is actually what we do in crosvm. It works pretty well but has a > few limitations: > > - Setting up the uidmap and gidmap requires CAP_SETUID and CAP_SETGID > (unless you're only mapping in the current euid/egid) so a user > without sudo access cannot do it. > - The daemon cannot do anything that requires caps in the init > namespace. For example, it cannot set any security.* or trusted.* > xattrs but that can be worked around by re-mapping them into the > user.* xattr namespace. Another example is anything to do with > filesystem quotas. We deal with this by forwarding them to another > daemon running in the init namespace but it's not ideal.
As of now probably "chown" is another limitation. One has to chown all uid/gid to appropriate mapping. Also if directory is shared between two VMs, then they have to be using same uid/gid map. Vivek > > Overall I think we're pretty happy with the user namespace sandbox. I > think the benefit of dropping all privileges in the init namespace has > been worth the cost of dealing with the limitations we've run into so > far. > > Chirantan > > _______________________________________________ > Virtio-fs mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/virtio-fs _______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
