qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 23/24] vhost-user-fs: Implement drop CAP_FSETID functionality


From: Stefan Hajnoczi
Subject: Re: [PATCH 23/24] vhost-user-fs: Implement drop CAP_FSETID functionality
Date: Mon, 22 Feb 2021 16:53:19 +0000

On Tue, Feb 16, 2021 at 10:57:10AM -0500, Vivek Goyal wrote:
> On Mon, Feb 15, 2021 at 03:57:11PM +0000, Stefan Hajnoczi wrote:
> > On Thu, Feb 11, 2021 at 09:40:31AM -0500, Vivek Goyal wrote:
> > > On Thu, Feb 11, 2021 at 02:35:42PM +0000, Stefan Hajnoczi wrote:
> > > > On Tue, Feb 09, 2021 at 07:02:23PM +0000, Dr. David Alan Gilbert (git) 
> > > > wrote:
> > > > > From: Vivek Goyal <vgoyal@redhat.com>
> > > > > 
> > > > > As part of slave_io message, slave can ask to do I/O on an fd. 
> > > > > Additionally
> > > > > slave can ask for dropping CAP_FSETID (if master has it) before doing 
> > > > > I/O.
> > > > > Implement functionality to drop CAP_FSETID and gain it back after the
> > > > > operation.
> > > > > 
> > > > > This also creates a dependency on libcap-ng.
> > > > 
> > > > Is this patch only for the case where QEMU is running as root?
> > > > 
> > > 
> > > Yes, it primarily is for the case where qemu is running as root, or
> > > somebody managed to launch it non-root but with still having capability
> > > CAP_FSETID.
> > 
> > Running QEMU as root is not encouraged because the security model is
> > designed around the principle of least privilege (only give QEMU access
> > to resources that belong to the guest).
> > 
> > What happens in the case where QEMU is not root? Does that mean QEMU
> > will drop suid/guid bits even if the FUSE client wanted them to be
> > preserved?
> 
> QEMU will drop CAP_FSETID only if vhost-user slave asked for it. There
> is no notion of gaining CAP_FSETID.
> 
> IOW, yes, if qemu is running unpriviliged and does not have CAP_FSETID,
> then we will end up clearing setuid bit on host. Not sure how that
> problem can be fixed.

Yeah, that seems problematic since the suid bit should stay set in that
case. The host cannot set the bit again (even if it has privileges)
because that would create a race condition where the guest expects the
bit set but it's cleared.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]