Bug 1034524

Summary: guest-fsfreeze-status doesn't return which keeps size of fsfreeze-hook.log in guest inceasing
Product: Red Hat Enterprise Linux 7 Reporter: Chao Yang <chayang>
Component: qemu-kvmAssignee: Laszlo Ersek <lersek>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: acathrow, dwalsh, hhuang, juzhang, lersek, mgrepl, michen, qzhang, sluo, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-03 14:38:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Chao Yang 2013-11-26 03:13:42 UTC
Description of problem:
Sending "guest-fsfreeze-status" to guest caused size of fsfreeze-hook.log in guest increased continuously. And command "guest-fsfreeze-status" didn't return.

Version-Release number of selected component (if applicable):
qemu-kvm-1.5.3-19.el7.x86_64
qemu-guest-agent-1.5.3-19.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
CLI:
/usr/libexec/qemu-kvm -S -m 4096 -smp 2,sockets=2,cores=1,threads=1 -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,path=/opt/qga.socket,id=qga_socket,server,nowait -device virtserialport,chardev=qga_socket,name=org.qemu.guest_agent.0 -drive file=rhel7.0.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-blk-pci,scsi=off,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=68:1a:4a:42:48:22,bus=pci.0 -vnc :1 -monitor stdio 

In guest:
# systemctl status qemu-guest-agent -l
qemu-guest-agent.service - QEMU Guest Agent
   Loaded: loaded (/usr/lib/systemd/system/qemu-guest-agent.service; static)
   Active: active (running) since Mon 2013-11-25 18:15:47 CST; 5min ago
 Main PID: 568 (qemu-ga)
   CGroup: /system.slice/qemu-guest-agent.service
           ├─ 568 /usr/bin/qemu-ga --method=virtio-serial --path=/dev/virtio-ports/org.qemu.guest_agent.0 --blacklist=guest-file-open guest-file-close guest-file-read guest-file-write guest-file-seek guest-file-flush -F/etc/qemu-ga/fsfreeze-hook
           ├─2791 /bin/bash /etc/qemu-ga/fsfreeze-hook freeze
           ├─2799 /bin/bash /etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook freeze
           ├─2805 /bin/bash /etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook freeze
           ├─2811 /bin/bash /etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook freeze
           ├─2817 /bin/bash /etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook freeze

......
          ├─7633 /bin/bash /etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook freeze
           ├─7639 /bin/bash /etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook freeze
           ├─7645 /bin/bash /etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook freeze
           ├─7649 n/a
           └─7650 n/a

Nov 25 18:15:47 localhost.localdomain systemd[1]: Started QEMU Guest Agent.
Nov 25 18:20:53 localhost.localdomain qemu-ga[568]: info: guest-fsfreeze called
Nov 25 18:20:53 localhost.localdomain qemu-ga[568]: info: executing fsfreeze hook with arg 'freeze'
Nov 25 18:20:57 localhost.localdomain python[2794]: SELinux is preventing /usr/bin/bash from read access on the file /etc/passwd.
                                                    
                                                    *****  Plugin catchall (100. confidence) suggests   **************************
                                                    
                                                    If you believe that bash should be allowed read access on the passwd file by default.
                                                    Then you should report this as a bug.
                                                    You can generate a local policy module to allow this access.
                                                    Do
                                                    allow this access for now by executing:
                                                    # grep fsfreeze-hook /var/log/audit/audit.log | audit2allow -M mypol
                                                    # semodule -i mypol.pp
                                                    
Nov 25 18:20:58 localhost.localdomain python[2794]: SELinux is preventing /usr/bin/bash from read access on the file /etc/passwd.
                                                    
                                                    *****  Plugin catchall (100. confidence) suggests   **************************
                                                    
                                                    If you believe that bash should be allowed read access on the passwd file by default.
                                                    Then you should report this as a bug.
                                                    You can generate a local policy module to allow this access.
                                                    Do
                                                    allow this access for now by executing:
                                                    # grep fsfreeze-hook /var/log/audit/audit.log | audit2allow -M mypol
                                                    # semodule -i mypol.pp
                                                    
Nov 25 18:20:58 localhost.localdomain python[2794]: SELinux is preventing /usr/bin/bash from getattr access on the file /etc/passwd.
                                                    
                                                    *****  Plugin catchall (100. confidence) suggests   **************************
                                                    
                                                    If you believe that bash should be allowed getattr access on the passwd file by default.
                                                    Then you should report this as a bug.
                                                    You can generate a local policy module to allow this access.
                                                    Do
                                                    allow this access for now by executing:
                                                    # grep fsfreeze-hook /var/log/audit/audit.log | audit2allow -M mypol
                                                    # semodule -i mypol.pp

Comment 2 Laszlo Ersek 2013-12-17 20:49:13 UTC
Dan, Miroslav, have you seen anything like this before?

(My understanding was that we had sorted out all SELinux permissions for the guest agent even in the RHEL-7 guest -- maybe something changed. Maybe /etc/passwd got locked down more strictly.)

Thanks!
Laszlo

Comment 3 Laszlo Ersek 2014-01-03 14:38:38 UTC
I cannot reproduce this bug with the most recent package versions. (Please see the details below.) Hence I'm closing it as CURRENTRELEASE. If you can reproduce the problem with the most recent packages, please reopen.

First, I don't know why python is listed in the problem report at all. We don't supply python hook scripts, so I have to assume this was a custom python hook script. But it hasn't been attached to the bug report, so I have no clue what it tries to do. That said, I did write a trivial python hook script, and it works.

I also have no idea what "/etc/qemu-ga/fsfreeze-hook.d/fsfreeze-hook" stands for; it is not part of the latest qemu-guest-agent package. So I have to assume again that this was a custom hook shell script (with unknown contents).

I tested with the following guest packages:
- qemu-guest-agent-1.5.3-30.el7.x86_64
- selinux-policy-3.12.1-110.el7.noarch
- selinux-policy-targeted-3.12.1-110.el7.noarch

Hook scripts:

  # ls -lZ /etc/qemu-ga/fsfreeze-hook.d/
  -rwxr-xr-x. root root system_u:object_r:virt_qemu_ga_unconfined_exec_t:s0 hello.py
  -rwxr-xr-x. root root system_u:object_r:virt_qemu_ga_unconfined_exec_t:s0 test.sh

Contents of "hello.py":

  #!/usr/bin/python
  print "Hello world!"

Contents of "test.sh"

  #!/bin/bash
  /bin/echo -E "$0:" "$@"

I ran several cycles of the following four commands:
  {"execute":"guest-fsfreeze-status"}
  {"execute":"guest-fsfreeze-freeze"}
  {"execute":"guest-fsfreeze-status"}
  {"execute":"guest-fsfreeze-thaw"}

They all succeeded. The output of the hook scripts was appended to "/var/log/qemu-ga/fsfreeze-hook.log" correspondingly, eg.

Fri Jan  3 15:25:19 CET 2014: execute /etc/qemu-ga/fsfreeze-hook.d/hello.py thaw
Hello world!
Fri Jan  3 15:25:19 CET 2014: /etc/qemu-ga/fsfreeze-hook.d/hello.py finished with status=0
Fri Jan  3 15:25:19 CET 2014: execute /etc/qemu-ga/fsfreeze-hook.d/test.sh thaw
/etc/qemu-ga/fsfreeze-hook.d/test.sh: thaw
Fri Jan  3 15:25:19 CET 2014: /etc/qemu-ga/fsfreeze-hook.d/test.sh finished with status=0