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

Re: [libvirt] Building on Solaris 11 Express

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,
        VIR_ERROR(_("additional privileges are required"));
        return -1;

        VIR_ERROR(_("failed to set reduced privileges"));
        return -1;

    return 0;
# define qemudSetupPrivs() 0

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?



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