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

Re: [libvirt] [PATCH] Fix sanlock socket security labelling



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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


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