Daniel P. Berrange wrote:
> On Tue, Dec 20, 2011 at 12:07:00PM -0700, Jim Fehlig wrote:
>
>> Daniel P. Berrange wrote:
>>
>>> On Tue, Dec 20, 2011 at 08:59:48AM -0700, Jim Fehlig wrote:
>>>
>>>
>>>> xhu wrote:
>>>>
>>>>
>>>>> On 12/16/2011 11:33 AM, Jim Fehlig wrote:
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I've noticed a regression in libvirt 0.9.8 on some of my kvm test machines
>>>>>>
>>>>>> # virsh start opensuse12
>>>>>> error: Failed to start domain opensuse12
>>>>>> error: Cannot open network interface control socket: Permission denied
>>>>>>
>>>>>>
>>>>> For I can't reproduce it on my machine with 0.9.8, can you provide me
>>>>> the detailed steps?
>>>>>
>>>>>
>>>> Nothing special, basic domain config using file-backed disk and
>>>> connecting to a bridge.
>>>>
>>>>
>>>>
>>>>> Also your os, libvirt, qemu-kvm and kernel version?
>>>>>
>>>>>
>>>> Yeah, it has something to do with the kernel, glibc, or other such
>>>> component. qemu-kvm isn't the problem as the error occurs before it is
>>>> invoked.
>>>>
>>>> kernel 3.1.0, glibc 2.14.1 (openSUSE12.1):
>>>> With libvirt 0.9.7, starting the domain works. This version of libvirt
>>>> opens control socket with 'socket(AF_INET, SOCK_STREAM, 0)'. With
>>>> libvirt 0.9.8, the domain does not start. In this version, the control
>>>> socket is opened with 'socket(AF_PACKET, SOCK_DGRAM, 0)', which fails
>>>> with EACCES.
>>>>
>>>> kernel 3.0.13, glibc 2.11.3 (SLES11 SP2):
>>>> Regression between libvirt 0.9.7 and 0.9.8 not observed.
>>>>
>>>> Initially, I assumed the bug was in glibc. But I can open packet(7)
>>>> sockets in a test program running as uid=euid=0, just not within
>>>> libvirtd running with same privileges.
>>>>
>>>>
>>> Interesting, this is very bizarre. I assume that if you patch
>>> libvirt 0.9.8 to use AF_INET again, it'll work fine ?
>>>
>>>
>> Yes, it is bizarre and yes, using AF_INET works.
>>
>>
>>> Is there any other access control mechanism in force like SELinux
>>> or AppArmour ?
>>>
>>>
>> No, which is why I'm rather confused...
>>
>
> Do you have a stack trace for the socket() call which generates
> EACCESS ? I'm wondering if there is any chance that the call
> is being made during the startup of QEMU inbetween fork() & exec()
> where we might have already dropped some capabilities ?
>
I don't think this is the case. IIUC, the qemu process hasn't been
started yet:
Breakpoint 1, virNetDevSetupControlFull (ifname=0x7fca880e7b90 "vnet0",
ifr=0x7fca92900c90, domain=17,
type=2) at util/virnetdev.c:55
55 {
(gdb) n
58 memset(ifr, 0, sizeof(*ifr));
(gdb)
60 if (virStrcpyStatic(ifr->ifr_name, ifname) == NULL) {
(gdb)
67 fd = socket(domain, type, 0);
(gdb)
68 if (fd < 0) {
(gdb) p fd
$1 = -1
(gdb) p errno
$2 = 13
(gdb) bt
#0 virNetDevSetupControlFull (ifname=0x7fca880e7b90 "vnet0",
ifr=0x7fca92900c90, domain=17, type=2)
at util/virnetdev.c:68
#1 0x00007fca99c36d4a in virNetDevSetupControl (ifname=0x7fca880e7b90
"vnet0", ifr=0x7fca92900c90)
at util/virnetdev.c:88
#2 0x00007fca99c36eab in virNetDevSetMAC (ifname=0x7fca880e7b90 "vnet0",
macaddr=0x7fca92900db0 "\376T") at util/virnetdev.c:154
#3 0x00007fca99c3bdef in virNetDevTapCreateInBridgePort
(brname=0x7fca880e7b70 "br0",
ifname=0x7fca880e9b78, macaddr=0x7fca92900db0 "\376T", vnet_hdr=1,
up=true, tapfd=0x7fca92900d8c)
at util/virnetdevtap.c:279
#4 0x000000000047e6f5 in qemuNetworkIfaceConnect (def=0x7fca880e9190,
conn=0x7fca84000ae0,
driver=0x7fca88068b10, net=0x7fca880e9b20, qemuCaps=0x7fca880e96e0)
at qemu/qemu_command.c:249
#5 0x000000000048a7d7 in qemuBuildCommandLine (conn=0x7fca84000ae0,
driver=0x7fca88068b10,
def=0x7fca880e9190, monitor_chr=0x7fca880e6180, monitor_json=true,
qemuCaps=0x7fca880e96e0,
migrateFrom=0x0, migrateFd=-1, snapshot=0x0,
vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE)
at qemu/qemu_command.c:4374
#6 0x00000000004af22a in qemuProcessStart (conn=0x7fca84000ae0,
driver=0x7fca88068b10,
vm=0x7fca880e9e30, migrateFrom=0x0, start_paused=false,
autodestroy=false, stdin_fd=-1,
stdin_path=0x0, snapshot=0x0,
vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE) at qemu/qemu_process.c:3094
#7 0x000000000046692b in qemuDomainObjStart (conn=0x7fca84000ae0,
driver=0x7fca88068b10,
vm=0x7fca880e9e30, flags=0) at qemu/qemu_driver.c:4704
#8 0x0000000000466bba in qemuDomainStartWithFlags (dom=0x7fca880e6260,
flags=0)
at qemu/qemu_driver.c:4761
#9 0x0000000000466c4e in qemuDomainStart (dom=0x7fca880e6260) at
qemu/qemu_driver.c:4780
#10 0x00007fca99cc6d2a in virDomainCreate (domain=0x7fca880e6260) at
libvirt.c:7629
#11 0x0000000000427b9f in remoteDispatchDomainCreate (server=0x7b6c60,
client=0x7be250, msg=0x800440,
rerr=0x7fca92901bb0, args=0x7fca880e62a0) at remote_dispatch.h:794
#12 0x0000000000427aa6 in remoteDispatchDomainCreateHelper
(server=0x7b6c60, client=0x7be250,
msg=0x800440, rerr=0x7fca92901bb0, args=0x7fca880e62a0,
ret=0x7fca880e6240)
at remote_dispatch.h:772
#13 0x00007fca99d21ef4 in virNetServerProgramDispatchCall
(prog=0x7c0210, server=0x7b6c60,
client=0x7be250, msg=0x800440) at rpc/virnetserverprogram.c:416
#14 0x00007fca99d21a8a in virNetServerProgramDispatch (prog=0x7c0210,
server=0x7b6c60,
client=0x7be250, msg=0x800440) at rpc/virnetserverprogram.c:289
#15 0x00007fca99d1b287 in virNetServerHandleJob (jobOpaque=0x79bac0,
opaque=0x7b6c60)
at rpc/virnetserver.c:164
#16 0x00007fca99c29892 in virThreadPoolWorker (opaque=0x7c01a0) at
util/threadpool.c:144
#17 0x00007fca99c292bb in virThreadHelper (data=0x7bf9d0) at
util/threads-pthread.c:157
#18 0x00007fca96025f05 in start_thread () from /lib64/libpthread.so.0
#19 0x00007fca9596153d in clone () from /lib64/libc.so.6
Thanks,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list