From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S62MC-0002vL-L3 for qemu-devel@nongnu.org; Fri, 09 Mar 2012 11:07:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S62M5-0003AZ-VT for qemu-devel@nongnu.org; Fri, 09 Mar 2012 11:07:52 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:42727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S62M5-0003AH-LU for qemu-devel@nongnu.org; Fri, 09 Mar 2012 11:07:45 -0500 Received: by bkcjg9 with SMTP id jg9so1469785bkc.4 for ; Fri, 09 Mar 2012 08:07:43 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F5A1DBB.3030606@laine.org> References: <20120309141653.GH4883@orkuz.home> <4F5A1DBB.3030606@laine.org> Date: Fri, 9 Mar 2012 16:07:43 +0000 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QEMU fstatfs(2) and libvirt SELinux policy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: libvir-list@redhat.com, Khoa Huynh , George Wilson , qemu-devel , Laine Stump On Fri, Mar 9, 2012 at 3:11 PM, Laine Stump wrote: > On 03/09/2012 09:16 AM, Jiri Denemark wrote: >> Hi. >> >> On Fri, Mar 09, 2012 at 11:32:47 +0000, Stefan Hajnoczi wrote: >> ... >>> static __inline__ int platform_test_xfs_fd(int fd) >>> { >>> =A0 =A0 =A0 =A0 struct statfs buf; >>> =A0 =A0 =A0 =A0 if (fstatfs(fd, &buf) < 0) >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; >>> =A0 =A0 =A0 =A0 return (buf.f_type =3D=3D 0x58465342); =A0 =A0 =A0/* XF= SB */ >>> } >>> >>> In other words, XFS detection will fail when SELinux is enabled. >>> >>> I'm not familiar with libvirt's use of SELinux. =A0Can someone explain >>> if we need to expand the policy in libvirt and how to do that? >> Actually, there is no SELinux policy in libvirt. Libvirt merely uses an >> appropriate security context when running qemu processes. The rules what= such >> processes can do and what they are forbidden to do are described in SELi= nux >> policy which is provided as a separate package (or packages on some dist= ros). >> So it's this policy (selinux-policy package on Fedora based distros) whi= ch >> would need to be expanded. Thus it should be negotiated with SELinux pol= icy >> maintainers if they are willing to allow svirt_t domain calling fstatfs. > > (Also, since the problem occurs on NFS, this may need to be somehow > related to virt_use_nfs being turned on.) > > As far as I understand from the conversation yesterday, this use of > fstatfs was added into qemu as part of a "hack" to improve performance > of guests whose images were on NFS shares. This was a problem in > RHEL6.1, for example. The lower level problems that caused poor > performance of images on NFS and necessitated this problem have been > fixed and, for example, are already in RHEL6.2, so the code is in the > process of being removed from QEMU. > > So am I correct that this extra permission is only needed for a single > RHEL6 release? If qemu won't be doing fstafs on an ongoing basis, it > doesn't seem like a good idea to permanently open up the permissions > allowed by virt_use_nfs Paolo, your discard improvements in QEMU add FALLOC_FL_PUNCH_HOLE support. XFS supports this fallocate() flag in current kernels, thereby making the XFS-specific support obsolete. I'm wondering whether it's worth expanding the SELinux policy if we will have no fstatfs(2) callers in QEMU. Are you planning to drop the XFS code? Stefan