xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: xen.org <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [qemu-upstream-4.3-testing baseline test] 20079: tolerable FAIL
Date: Thu, 3 Oct 2013 19:38:40 +0100	[thread overview]
Message-ID: <osstest-20079-mainreport@xen.org> (raw)

"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 20079 qemu-upstream-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/20079/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop              fail never pass
 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-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass

version targeted for testing:
 qemuu                5fefb0fa48e72488f37f0012ee18c93beeac1388
baseline version:
 qemuu                7483e7f15139603380c45ebcd8cc2a57dda5583c

------------------------------------------------------------
People who touched revisions under test:
  Anthony Liguori <aliguori@us.ibm.com>
  Daniel P. Berrange <berrange@redhat.com>
  Laszlo Ersek <lersek@redhat.com>
  Paolo Bonzini <pbonzini@redhat.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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 5fefb0fa48e72488f37f0012ee18c93beeac1388
Author: Laszlo Ersek <lersek@redhat.com>
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@redhat.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

commit 5b73c63c86b80197f1be12feb32625d203833f09
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Tue Oct 1 14:59:14 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@redhat.com>
    [Use errx, not err. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

                 reply	other threads:[~2013-10-03 18:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=osstest-20079-mainreport@xen.org \
    --to=ian.jackson@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).