[libvirt] possible 0.9.8 regression?

[Jim Fehlig]

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