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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list