[Bug 1620407] Re: vm startup broken when interface definition has script tag

ChristianEhrhardt 1620407 at bugs.launchpad.net
Mon Feb 6 14:50:32 UTC 2017


** Description changed:

+ Regression restricted to set script which is rare as it is a massive
+ security drop
+ 
+ [Impact]
+ 
+  * A user using a type "ethernet" device with a custom script as working 
+    in Trusty runs into an error on Xenial.
+ 
+  * Essentially Xenials libvirt "only" stumbles over a check&add on an 
+    index for that network device. But since it might be externally created 
+    later (up until on qemu start) it might not be available at the time it 
+    is checking. So the fix skips the check index in those cases.
+ 
+  * The fix as-is is not upstream because upstream opted for a fare bigger 
+    rework of the section in which after 9c17d665fdc5f "autocreate tap 
+    device for ethernet network type" libvirt calls the script. That also 
+    allows different security levels (permission of libvirt instead of 
+    qemu) but these changes are huge and not sufficient for an SRU fix.
+ 
+ [Test Case]
+ 
+  * Create a guest your usual way (e.g. uvtool-libvirt
+  * Add a script based type network ethernet device (there is no need to 
+    create a script, one can use the default of qemu). The xml snippet 
+    looks like this:
+     <interface type='ethernet'>
+       <mac address='52:54:00:18:0d:a3'/>
+       <script path='/etc/qemu-ifup'/>
+       <target dev='newdevname'/>
+       <model type='virtio'/>
+     </interface>
+ 
+  * without the fix this runs into:
+    error: Failed to start domain <guestname>
+    error: Unable to get index for interface <devicename>: No such device
+ 
+ [Regression Potential]
+ 
+  * There could be a cornercase around nicindexes which due to the skip in    
+    case net->skript is set that was not covered in our experiments now 
+    failing. But since as of today setting the script tag in generally 
+    fails those people should not exist.
+ 
+  * Another fact that limits the potential regression is that type ethernet 
+    devices come at a huge security disadvantage - it needs to run 
+    privileged as root and also disable certain security features (not 
+    clearing capabilities for example).
+    That said the number of users still using that feature should be low 
+    and shrinking further.
+ 
+ [Other Info]
+  
+  * n/a
+ 
+ 
+ 
+ ----- original report -----
+ 
+ 
+ 
  Ubuntu 16.04.1 LTS (amd64)
  libvirt-bin 1.3.1-1ubuntu10.1
  
  We use external scripts to setup tap interfaces, e.g.
  
-     <interface type='ethernet'>
-       <mac address='52:54:00:18:0d:a3'/>
-       <script path='/etc/libvirt/14v/mf_testet.sh'/>
-       <target dev='mf_testet'/>
-       <model type='virtio'/>
-       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
-     </interface>
+     <interface type='ethernet'>
+       <mac address='52:54:00:18:0d:a3'/>
+       <script path='/etc/libvirt/14v/mf_testet.sh'/>
+       <target dev='mf_testet'/>
+       <model type='virtio'/>
+       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+     </interface>
  
  Starting the VM throws an error message ("interface not found" or
  something like that).
  
  IIUC, the script invocation is done by qemu, so the interface
  may not yet exist when libvirt is constructing the qemu cmd args.
  Checking for that interface in advance therefore is a bug.
  
  Attached patch skips the check if a <script> parameter is provided.
  
  Regards
  Matthias Ferdinand

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1620407

Title:
  vm startup broken when interface definition has script tag

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  In Progress

Bug description:
  Regression restricted to set script which is rare as it is a massive
  security drop

  [Impact]

   * A user using a type "ethernet" device with a custom script as working 
     in Trusty runs into an error on Xenial.

   * Essentially Xenials libvirt "only" stumbles over a check&add on an 
     index for that network device. But since it might be externally created 
     later (up until on qemu start) it might not be available at the time it 
     is checking. So the fix skips the check index in those cases.

   * The fix as-is is not upstream because upstream opted for a fare bigger 
     rework of the section in which after 9c17d665fdc5f "autocreate tap 
     device for ethernet network type" libvirt calls the script. That also 
     allows different security levels (permission of libvirt instead of 
     qemu) but these changes are huge and not sufficient for an SRU fix.

  [Test Case]

   * Create a guest your usual way (e.g. uvtool-libvirt
   * Add a script based type network ethernet device (there is no need to 
     create a script, one can use the default of qemu). The xml snippet 
     looks like this:
      <interface type='ethernet'>
        <mac address='52:54:00:18:0d:a3'/>
        <script path='/etc/qemu-ifup'/>
        <target dev='newdevname'/>
        <model type='virtio'/>
      </interface>

   * without the fix this runs into:
     error: Failed to start domain <guestname>
     error: Unable to get index for interface <devicename>: No such device

  [Regression Potential]

   * There could be a cornercase around nicindexes which due to the skip in    
     case net->skript is set that was not covered in our experiments now 
     failing. But since as of today setting the script tag in generally 
     fails those people should not exist.

   * Another fact that limits the potential regression is that type ethernet 
     devices come at a huge security disadvantage - it needs to run 
     privileged as root and also disable certain security features (not 
     clearing capabilities for example).
     That said the number of users still using that feature should be low 
     and shrinking further.

  [Other Info]
   
   * n/a



  ----- original report -----


  
  Ubuntu 16.04.1 LTS (amd64)
  libvirt-bin 1.3.1-1ubuntu10.1

  We use external scripts to setup tap interfaces, e.g.

      <interface type='ethernet'>
        <mac address='52:54:00:18:0d:a3'/>
        <script path='/etc/libvirt/14v/mf_testet.sh'/>
        <target dev='mf_testet'/>
        <model type='virtio'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
      </interface>

  Starting the VM throws an error message ("interface not found" or
  something like that).

  IIUC, the script invocation is done by qemu, so the interface
  may not yet exist when libvirt is constructing the qemu cmd args.
  Checking for that interface in advance therefore is a bug.

  Attached patch skips the check if a <script> parameter is provided.

  Regards
  Matthias Ferdinand

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1620407/+subscriptions



More information about the Ubuntu-sponsors mailing list