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

[Stefan Hajnoczi]

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 <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.

Cool, thanks for sharing those details!

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/20210120/c3f5a15c/attachment.sig>