Re: [libvirt] Building on Solaris 11 Express
On Mon, May 30, 2011 at 08:52, Matthias Bolte
<matthias.bolte(a)googlemail.com> wrote:
2011/5/30 Ruben Kerkhof <ruben(a)rubenkerkhof.com>:
> On Sun, May 29, 2011 at 19:45, Matthias Bolte
> <matthias.bolte(a)googlemail.com> wrote:
>> 2011/5/29 Richard Laager <rlaager(a)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.
>>>
>>>> '(a)//.libvirt/libvirt-sock' should actually look like this
>>>> '(a)/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