[libvirt] Building on Solaris 11 Express

[Matthias Bolte]

2011/6/3 Ruben Kerkhof <ruben at rubenkerkhof.com>:
> On Mon, May 30, 2011 at 08:52, Matthias Bolte
> <matthias.bolte at googlemail.com> wrote:
>> 2011/5/30 Ruben Kerkhof <ruben at rubenkerkhof.com>:
>>> On Sun, May 29, 2011 at 19:45, Matthias Bolte
>>> <matthias.bolte at googlemail.com> wrote:
>>>> 2011/5/29 Richard Laager <rlaager at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-daemon-Fix-privileged-mode-detection-on-Solaris.patch
Type: text/x-patch
Size: 2332 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110603/082a1ec0/attachment-0001.bin>