[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd
Date: Tue, 10 Jul 2012 09:58:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Am 09.07.2012 20:40, schrieb Anthony Liguori:
> On 06/26/2012 04:10 AM, Daniel P. Berrange wrote:
>> On Fri, Jun 22, 2012 at 02:36:07PM -0400, Corey Bryant wrote:
>>> libvirt's sVirt security driver provides SELinux MAC isolation for
>>> Qemu guest processes and their corresponding image files.  In other
>>> words, sVirt uses SELinux to prevent a QEMU process from opening
>>> files that do not belong to it.
>>> sVirt provides this support by labeling guests and resources with
>>> security labels that are stored in file system extended attributes.
>>> Some file systems, such as NFS, do not support the extended
>>> attribute security namespace, and therefore cannot support sVirt
>>> isolation.
>>> A solution to this problem is to provide fd passing support, where
>>> libvirt opens files and passes file descriptors to QEMU.  This,
>>> along with SELinux policy to prevent QEMU from opening files, can
>>> provide image file isolation for NFS files stored on the same NFS
>>> mount.
>>> This patch series adds the pass-fd QMP monitor command, which allows
>>> an fd to be passed via SCM_RIGHTS, and returns the received file
>>> descriptor.  Support is also added to the block layer to allow QEMU
>>> to dup the fd when the filename is of the /dev/fd/X format.  This
>>> is useful if MAC policy prevents QEMU from opening specific types
>>> of files.
>> I was thinking about some of the sources complexity when using
>> FD passing from libvirt and wanted to raise one idea for discussion
>> before we continue.
>> With this proposed series, we have usage akin to:
>>    1. pass_fd FDSET={M} ->  returns a string "/dev/fd/N" showing QEMU's
>>       view of the FD
>>    2. drive_add file=/dev/fd/N
>>    3. if failure:
>>         close_fd "/dev/fd/N"
>> My problem is that none of this FD passing is "transactional".
> My original patch series did not suffer from this problem.
> QEMU owned the file descriptor once it received it from libvirt.
> I don't think the cited problem (QEMU failing an operation if libvirt was 
> down) 
> is really an actual problem since it would be libvirt that would be issuing 
> the 
> command in the first place (so the command would just fail which libvirt 
> would 
> have to assume anyway if it crashed).
> I really dislike where this thread has headed with /dev/fdset.  This has 
> become 
> extremely complex and cumbersome.

What exactly is complex about the interface we're going to provide? A
long discussion about how to get the details implemented best doesn't
mean at all that the result is complex.

> Perhaps we should reconsider using an RPC for QEMU to request an fd as this 
> solves all the cited problems in a much simpler fashion.

NACK. RPC is wrong and no way easier to handle for management.


reply via email to

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