[libvirt] Building on Solaris 11 Express

[Ruben Kerkhof]

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