[libvirt] [PATCH] Fix sanlock socket security labelling

Eric Blake eblake at redhat.com
Tue Aug 30 16:48:41 UTC 2011


On 08/30/2011 10:37 AM, Daniel P. Berrange wrote:
> It is not possible to change the label of a TCP socket once it
> has been opened. When creating a TCP socket care must be taken
> to ensure the socket creation label is set&  then cleared.
> Remove the bogus call to virSecurityManagerSetProcessFDLabel
> from the lock driver guest setup code and instead make use of
> virSecurityManagerSetSocketLabel
> ---
>   src/qemu/qemu_process.c |   19 ++++++++++++-------
>   1 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 58b4d36..c22974f 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -2081,15 +2081,26 @@ static int qemuProcessHook(void *data)
>       h->vm->pid = getpid();
>
>       VIR_DEBUG("Obtaining domain lock");
> +    /*
> +     * Since we're going to leak the returned FD to QEMU,
> +     * we need to make sure it gets a sensible label.
> +     * This mildly sucks, because there could be other
> +     * sockets the lock driver opens that we don't want
> +     * labelled. So far we're ok though.
> +     */

Is there any way to trace which socket fds the callback ends up 
creating?  But then again, what good does that do, since there's no way 
for us to change the label post-creation, even if we detect that other 
socket fds were created.  Yeah, it does suck, and I think your solution 
is the best we're going to get.  (At least we already validated that the 
socket labelling code is thread-safe - it sets the default label for 
only those sockets created by the thread that requested the updated 
default socket label).

ACK.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org




More information about the libvir-list mailing list