Re: [libvirt] Building on Solaris 11 Express

On Mon, May 30, 2011 at 08:52, Matthias Bolte <matthias.bolte(a)googlemail.com&gt; wrote: > 2011/5/30 Ruben Kerkhof <ruben(a)rubenkerkhof.com&gt;: >> On Sun, May 29, 2011 at 19:45, Matthias Bolte >> <matthias.bolte(a)googlemail.com&gt; wrote: >>> 2011/5/29 Richard Laager <rlaager(a)wiktel.com&gt;: >>>> 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. >>>> >>>>> &#39;(a)//.libvirt/libvirt-sock&#39; should actually look like this >>>>> &#39;(a)/home/&lt;username&gt;/.libvirt/libvirt-sock&#39; 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