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

Chirantan Ekbote chirantan at chromium.org
Wed Jan 20 05:49:52 UTC 2021


On Tue, Jan 19, 2021 at 11:34 PM P J P <ppandit at redhat.com> 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.

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




More information about the Virtio-fs mailing list