[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