[Xen-devel] [qemu-upstream-4.2-testing baseline test] 20078: tolerable FAIL

[xen.org <ian.jackson@xxxxxxxxxxxxx>]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 20078 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/20078/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 qemuu                3389f492465406e48914ee88d6e990dcf4629682
baseline version:
 qemuu                59e2fb7252dbdc008a63d144b19be0cd8d873128

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@xxxxxxxxxx>
  Daniel P. Berrange <berrange@xxxxxxxxxx>
  Laszlo Ersek <lersek@xxxxxxxxxx>
  Paolo Bonzini <pbonzini@xxxxxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.

------------------------------------------------------------
commit 3389f492465406e48914ee88d6e990dcf4629682
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Tue Oct 1 15:20:40 2013 +0000

    qga: set umask 0077 when daemonizing (CVE-2013-2007)
    
    The qemu guest agent creates a bunch of files with insecure permissions
    when started in daemon mode. For example:
    
      -rw-rw-rw- 1 root root /var/log/qemu-ga.log
      -rw-rw-rw- 1 root root /var/run/qga.state
      -rw-rw-rw- 1 root root /var/log/qga-fsfreeze-hook.log
    
    In addition, at least all files created with the "guest-file-open" QMP
    command, and all files created with shell output redirection (or
    otherwise) by utilities invoked by the fsfreeze hook script are affected.
    
    For now mask all file mode bits for "group" and "others" in
    become_daemon().
    
    Temporarily, for compatibility reasons, stick with the 0666 file-mode in
    case of files newly created by the "guest-file-open" QMP call. Do so
    without changing the umask temporarily.
    
    upstream-commit-id: c689b4f1bac352dcfd6ecb9a1d45337de0f1de67
    
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Signed-off-by: Anthony Liguori <aliguori@xxxxxxxxxx>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>

commit 9af2b71301bd70c30c2bd21a084a6db85195fff5
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Tue Oct 1 15:00:18 2013 +0000

    Add -f FMT / --format FMT arg to qemu-nbd
    
    Currently the qemu-nbd program will auto-detect the format of
    any disk it is given. This behaviour is known to be insecure.
    For example, if qemu-nbd initially exposes a 'raw' file to an
    unprivileged app, and that app runs
    
       'qemu-img create -f qcow2 -o backing_file=/etc/shadow /dev/nbd0'
    
    then the next time the app is started, the qemu-nbd will now
    detect it as a 'qcow2' file and expose /etc/shadow to the
    unprivileged app.
    
    The only way to avoid this is to explicitly tell qemu-nbd what
    disk format to use on the command line, completely disabling
    auto-detection. This patch adds a '-f' / '--format' arg for
    this purpose, mirroring what is already available via qemu-img
    and qemu commands.
    
      qemu-nbd --format raw -p 9000 evil.img
    
    will now always use raw, regardless of what format 'evil.img'
    looks like it contains
    
    upstream-commit-id: e6b636779b51c97e67694be740ee972c52460c59
    
    Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>
    [Use errx, not err. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel