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

Re: [libvirt] Building on Solaris 11 Express



2011/6/3 Ruben Kerkhof <ruben rubenkerkhof com>:
> On Mon, May 30, 2011 at 08:52, Matthias Bolte
> <matthias bolte googlemail com> wrote:
>> 2011/5/30 Ruben Kerkhof <ruben rubenkerkhof com>:
>>> On Sun, May 29, 2011 at 19:45, Matthias Bolte
>>> <matthias bolte googlemail com> wrote:
>>>> 2011/5/29 Richard Laager <rlaager wiktel com>:
>>>>> On Sun, 2011-05-29 at 12:34 +0200, Matthias Bolte wrote:
>>>>>> > So I tried building libvirt on Solaris 11 Express. The following
>>>>>> > outlines the trouble (and successes) I've had so far.
>>>>>>
>>>>>> I assume your building from up-to-date git here?
>>>>>
>>>>> I was using 0.9.1. I should switch to git.
>>>>>
>>>>>> '@//.libvirt/libvirt-sock' should actually look like this
>>>>>> '@/home/<username>/.libvirt/libvirt-sock' as you're running libvirtd
>>>>>> as non-root it tries to open a UNIX socket in the home directory of
>>>>>> the user starting it. This path is build via this pattern:
>>>>>>
>>>>>>   @<home-directory>/.libvirt/libvirt-sock
>>>>>
>>>>> I was actually running it as root.
>>>>>
>>>>> Richard
>>>>>
>>>>
>>>> That's even stranger. libvirtd uses geteuid() == 0 to detect if it's
>>>> running as root and acts upon that. It only tries to open a UNIX
>>>> socket in the user's home (what it does in your case) when it detects
>>>> non-root execution. Something is wrong here, but I've no clue what.
>>>>
>>>> Matthias
>>>
>>> Only linux supports the abstract socket namespace.
>>> I ran into the same issue on OS X
>>> (http://www.redhat.com/archives/libvir-list/2010-October/msg00969.html)
>>>
>>> Kind regards,
>>>
>>> Ruben
>>
>> Okay, that's a related but different problem, I think.
>>
>> As far as I understood the situation here Richard is running libvirtd
>> as root. In that case libvirt should create the UNIX socket in
>> [/usr/local]/var/run/libvirt/libvirt-sock. Only when running libvirtd
>> as non-root it creates the UNIX socket in the abstract namespace, but
>> not in the roor case. Therefore, running libvirtd as root should work
>> on Solaris. But libvirtd seem to fail to detect being executed as
>> root. It tries to create the UNIX socket in a broken path in the
>> abstract namespace and this fails, but this is just a symptom, not the
>> actual problem.
>>
>> The question is why, libvirtd thinks it's running as non-root while
>> Richard says that he's running it as root.
>>
>> Matthias
>
> It has probably something to do with this piece of code, in daemon/libvirtd.c:
>
> #ifdef __sun
> static int
> qemudSetupPrivs (void)
> {
>    chown ("/var/run/libvirt", SYSTEM_UID, SYSTEM_UID);
>
>    if (__init_daemon_priv (PU_RESETGROUPS | PU_CLEARLIMITSET,
>        SYSTEM_UID, SYSTEM_UID, PRIV_XVM_CONTROL, NULL)) {
>        VIR_ERROR(_("additional privileges are required"));
>        return -1;
>    }
>
>    if (priv_set (PRIV_OFF, PRIV_ALLSETS, PRIV_FILE_LINK_ANY, PRIV_PROC_INFO,
>        PRIV_PROC_SESSION, PRIV_PROC_EXEC, PRIV_PROC_FORK, NULL)) {
>        VIR_ERROR(_("failed to set reduced privileges"));
>        return -1;
>    }
>
>    return 0;
> }
> #else
> # define qemudSetupPrivs() 0
> #endif
>
> This drops the privileges to those of the xvm user (SYSTEM_UID = 60)
> After that, in qemudInitialize(), geteuid() returns 60 and
> server->privileged is set to 0.
> Since server->privileged is 0, we try to create the abstract socket,
> which causes the error Richard is seeing.
>
> This looks like a side-effect from commit a71f79c3
>
> Makes sense?
>
> Thanks,
>
> Ruben
>

That might be the problem. I don't have a Solaris at hand right now to
test it so here is a speculative patch for this.

Matthias
From 1cc28b06b5e3ea349c772e398a8436de7a0351df Mon Sep 17 00:00:00 2001
From: Matthias Bolte <matthias bolte googlemail com>
Date: Fri, 3 Jun 2011 08:23:13 +0200
Subject: [PATCH] daemon: Fix privileged mode detection on Solaris

qemudSetupPrivs() drops privileges on Solaris making geteuid()
return non-zero later on when qemudInitialize() tries to detect
privileged mode.

Detect privileged mode before calling qemudSetupPrivs() to fix
this.

Reported by Richard Laager.
Figured out by Ruben Kerkhof.
---
 daemon/libvirtd.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index aec81cf..01b8bfc 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -868,7 +868,7 @@ static int daemonErrorLogFilter(virErrorPtr err, int priority)
 }
 
 
-static struct qemud_server *qemudInitialize(void) {
+static struct qemud_server *qemudInitialize(int privileged) {
     struct qemud_server *server;
 
     if (VIR_ALLOC(server) < 0) {
@@ -876,7 +876,7 @@ static struct qemud_server *qemudInitialize(void) {
         return NULL;
     }
 
-    server->privileged = geteuid() == 0 ? 1 : 0;
+    server->privileged = privileged;
     server->sigread = server->sigwrite = -1;
 
     if (virMutexInit(&server->lock) < 0) {
@@ -3160,6 +3160,8 @@ int main(int argc, char **argv) {
     const char *remote_config_file = NULL;
     int statuswrite = -1;
     int ret = 1;
+    int privileged;
+
     argv0 = argv[0];
 
     struct option opts[] = {
@@ -3300,8 +3302,12 @@ int main(int argc, char **argv) {
      * getuid/geteuid() == 0, for privilege level checks.
      * It must all use the flag 'server->privileged'
      * which is also passed into all libvirt stateful
-     * drivers
+     * drivers.
+     * Detect geteuid() == 0 before calling qemudSetupPrivs()
+     * because that might drop privileges.
      */
+    privileged = geteuid() == 0 ? 1 : 0;
+
     if (qemudSetupPrivs() < 0) {
         ret = VIR_DAEMON_ERR_PRIVS;
         goto error;
@@ -3312,7 +3318,7 @@ int main(int argc, char **argv) {
      * parse x590 certificates for seamless migration */
     gnutls_global_init();
 
-    if (!(server = qemudInitialize())) {
+    if (!(server = qemudInitialize(privileged))) {
         ret = VIR_DAEMON_ERR_INIT;
         goto error;
     }
-- 
1.7.0.4


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