2011/6/3 Ruben Kerkhof <ruben@xxxxxxxxxxxxxxxx>:
> On Mon, May 30, 2011 at 08:52, Matthias Bolte
> <matthias.bolte@xxxxxxxxxxxxxx> wrote:
>> 2011/5/30 Ruben Kerkhof <ruben@xxxxxxxxxxxxxxxx>:
>>> On Sun, May 29, 2011 at 19:45, Matthias Bolte
>>> <matthias.bolte@xxxxxxxxxxxxxx> wrote:
>>>> 2011/5/29 Richard Laager <rlaager@xxxxxxxxxx>:
>>>>> 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
From 1cc28b06b5e3ea349c772e398a8436de7a0351df Mon Sep 17 00:00:00 2001
From: Matthias Bolte <matthias.bolte@xxxxxxxxxxxxxx>
Date: Fri, 3 Jun 2011 08:23:13 +0200
Subject: [PATCH] daemon: Fix privileged mode detection on Solaris
qemudSetupPrivs() drops privileges on Solaris making geteuid()
return non-zero later on when qemudInitialize() tries to detect
privileged mode.
Detect privileged mode before calling qemudSetupPrivs() to fix
this.
Reported by Richard Laager.
Figured out by Ruben Kerkhof.
---
daemon/libvirtd.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index aec81cf..01b8bfc 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -868,7 +868,7 @@ static int daemonErrorLogFilter(virErrorPtr err, int priority)
}
-static struct qemud_server *qemudInitialize(void) {
+static struct qemud_server *qemudInitialize(int privileged) {
struct qemud_server *server;
if (VIR_ALLOC(server) < 0) {
@@ -876,7 +876,7 @@ static struct qemud_server *qemudInitialize(void) {
return NULL;
}
- server->privileged = geteuid() == 0 ? 1 : 0;
+ server->privileged = privileged;
server->sigread = server->sigwrite = -1;
if (virMutexInit(&server->lock) < 0) {
@@ -3160,6 +3160,8 @@ int main(int argc, char **argv) {
const char *remote_config_file = NULL;
int statuswrite = -1;
int ret = 1;
+ int privileged;
+
argv0 = argv[0];
struct option opts[] = {
@@ -3300,8 +3302,12 @@ int main(int argc, char **argv) {
* getuid/geteuid() == 0, for privilege level checks.
* It must all use the flag 'server->privileged'
* which is also passed into all libvirt stateful
- * drivers
+ * drivers.
+ * Detect geteuid() == 0 before calling qemudSetupPrivs()
+ * because that might drop privileges.
*/
+ privileged = geteuid() == 0 ? 1 : 0;
+
if (qemudSetupPrivs() < 0) {
ret = VIR_DAEMON_ERR_PRIVS;
goto error;
@@ -3312,7 +3318,7 @@ int main(int argc, char **argv) {
* parse x590 certificates for seamless migration */
gnutls_global_init();
- if (!(server = qemudInitialize())) {
+ if (!(server = qemudInitialize(privileged))) {
ret = VIR_DAEMON_ERR_INIT;
goto error;
}
--
1.7.0.4
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list