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 <vgo...@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. Vivek
