[Xen-devel] [qemu-upstream-unstable baseline test] 20054: 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 20054 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/20054/

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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass

version targeted for testing:
 qemuu                8a4bd762aa01b21c43aa24c5b743f4bd7c9db3e3
baseline version:
 qemuu                7483e7f15139603380c45ebcd8cc2a57dda5583c

------------------------------------------------------------
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    


------------------------------------------------------------
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 8a4bd762aa01b21c43aa24c5b743f4bd7c9db3e3
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Tue Oct 1 15:13:33 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 6dc71da698bfdc5297f8719e78eba26b1f15ff2c
Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
Date:   Tue Oct 1 14:50:32 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