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

Re: [libvirt] [Qemu-devel] QEMU fstatfs(2) and libvirt SELinux policy

On Fri, Mar 9, 2012 at 3:11 PM, Laine Stump <laine laine org> 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)
>>> {
>>>         struct statfs buf;
>>>         if (fstatfs(fd, &buf) < 0)
>>>                 return 0;
>>>         return (buf.f_type == 0x58465342);      /* XFSB */
>>> }
>>> In other words, XFS detection will fail when SELinux is enabled.
>>> I'm not familiar with libvirt's use of SELinux.  Can 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 SELinux
>> policy which is provided as a separate package (or packages on some distros).
>> So it's this policy (selinux-policy package on Fedora based distros) which
>> would need to be expanded. Thus it should be negotiated with SELinux policy
>> 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?


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