Bug 1223319

I guess I could compile Ceph without lttng-ust support but I need to investigate more on this to see if this is indeed a buggy behaviour.

btw: Are you sure this happened on update from -1 to -2? I really doubt that as the two releases differ only in a very tiny patch that does not touch the lttng-related code and is non-x86_64-specific.

btw2: Judging from the discussion, here

https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1432644

this is somewhat expected (you can either have this behaviour or the one that is in ubuntu at the moment). I guess I could disable lttng-ust trace points support for fedora builds but I'll need to search a bit more to make a more qualified decision.

I am not 100% sure but pretty sure nonetheless.

I pretty much update rawhide daily (although in this case i skipped a few days due to a kernel bug in rawhide). Anyhow after each update i restart my qemu guests.

This only started today, and today i updated to latest librados2. So even though i am not willing to bet my life on it, i am pretty sure.

A minimal qemu implementation shouldnt be doing this i hope? Also the messages i pasted above also signal that it would'nt work anyway?

Yeah, the AVC denial message should in fact stop qemu from creating the file but you seem to be running in Permissive mode so it does not. Did you by any chance set SELinux to Permissive mode between the librados updates? That would explain the change in the behaviour. (but the bug was there all along)

Apparently, other people are running into similar problems:

https://bugzilla.redhat.com/show_bug.cgi?id=1190461

Judging from these reports (this bz, launchpad, the other bz), the lttng-ust support currently looks experimental to me and I'll disable it for now (judging from Sage's comment in the launchpad, it is also the solution they chose for ubuntu).

Good observation. You are right about permissive mode.

That, however, does not change the fact that this behavior is probably unwanted and likely due to experimental code.

I agree that disabling this functionality for now is probably the best course of action.

ceph-0.94.1-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/FEDORA-2015-8189/ceph-0.94.1-3.fc22

I've submitted f22 update that should include patches for this. I've also pushed the change to f23 (rawhide):

http://koji.fedoraproject.org/koji/taskinfo?taskID=9814905

Feel free to test to see if it fixes your issue.

Yes, looks like that fixed the issue.

May 21 14:49:21 d30 systemd[1]: Stopping FedoraTest1 QEMU guest...
May 21 14:49:23 d30 kernel: br0: port 1(tap0) entered disabled state
May 21 14:49:23 d30 systemd-networkd[989]: tap0            : lost carrier
May 21 14:49:23 d30 systemd-timesyncd[979]: Network configuration changed, trying to establish connection.
May 21 14:49:23 d30 systemd[1]: Stopped FedoraTest1 QEMU guest.
May 21 14:49:23 d30 kernel: audit_printk_skb: 3 callbacks suppressed
May 21 14:49:23 d30 kernel: audit: type=1131 audit(1432212563.391:3365): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:syst
em_r:systemd_t msg='unit=fedoratest1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 21 14:49:23 d30 audit[1]: <audit-1131> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:systemd_t msg='unit=fedor
atest1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 21 14:49:23 d30 polkitd[1419]: Unregistered Authentication Agent for unix-process:10749:10160277 (system bus name :1.144, object p
ath /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
May 21 14:49:28 d30 polkitd[1419]: Registered Authentication Agent for unix-process:10764:10161029 (system bus name :1.145 [/usr/bin/p
kttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
May 21 14:49:28 d30 systemd[1]: Starting FedoraTest1 QEMU guest...
May 21 14:49:28 d30 kernel: br0: port 1(tap0) entered forwarding state
May 21 14:49:28 d30 kernel: br0: port 1(tap0) entered forwarding state
May 21 14:49:28 d30 systemd-networkd[989]: tap0            : gained carrier
May 21 14:49:28 d30 systemd-timesyncd[979]: Network configuration changed, trying to establish connection.
May 21 14:49:28 d30 myqemu_runner_tap[10770]: char device redirected to /dev/pts/2 (label serial0)
May 21 14:49:29 d30 systemd[1]: Started FedoraTest1 QEMU guest.
May 21 14:49:29 d30 kernel: audit: type=1130 audit(1432212569.013:3366): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:syst
em_r:systemd_t msg='unit=fedoratest1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 21 14:49:29 d30 audit[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:systemd_t msg='unit=fedor
atest1 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 21 14:49:29 d30 polkitd[1419]: Unregistered Authentication Agent for unix-process:10764:10161029 (system bus name :1.145, object p
ath /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
May 21 14:49:29 d30 kernel: kvm: zapping shadow pages for mmio generation wraparound
May 21 14:49:38 d30 kernel: kvm [10778]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0xffff
May 21 14:49:38 d30 kernel: kvm [10778]: vcpu0 unhandled rdmsr: 0x570
May 21 14:49:38 d30 kernel: kvm [10778]: vcpu1 unhandled rdmsr: 0x570
May 21 14:49:43 d30 kernel: br0: port 1(tap0) entered forwarding state

 ... thanks!

No problem, thanks for pointing this out. :)

Package ceph-0.94.1-3.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ceph-0.94.1-3.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-8189/ceph-0.94.1-3.fc22
then log in and leave karma (feedback).

Fixes selinux errors we were seeing via launching qemu VMs (which link to ceph): https://bugzilla.redhat.com/show_bug.cgi?id=1221945

FWIW in this other ubuntu bug, a dev suggests he worked around it in his code by making the tracepoints conditional on an env variable. Maybe that's an option for ceph: https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1404302

*** Bug 1221945 has been marked as a duplicate of this bug. ***

Description of problem:
Lauching a VM 

Version-Release number of selected component:
selinux-policy-3.13.1-126.fc22.noarch

Additional info:
reporter:       libreport-2.5.1
hashmarkername: setroubleshoot
kernel:         4.0.4-300.fc22.x86_64
type:           libreport

Description of problem:
Rebooted and received the warning. I use libvirtd/qemu/virt-manager for some vms

Version-Release number of selected component:
selinux-policy-3.13.1-126.fc22.noarch

Additional info:
reporter:       libreport-2.5.1
hashmarkername: setroubleshoot
kernel:         4.0.4-301.fc22.x86_64
type:           libreport

ceph-0.94.1-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Boris do we need a new bug to track the SELinux issue?

@Ken: Hmm, maybe but an upstream one. Although, I suspect/hope that the SELinux issue will get fixed once the shared device will have better permissions.

@Josh, was this the bug that we'd discussed yesterday re: SELinux and lttng-ust?

Yes, this is the lttng-ust issue we were talking about.