Comment 20 for bug 1845506

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

By single stepping the code I see that the Denies clearly come in after the second reload_profile added the rule - so it just should not happen?

Maybe the rules aren't reloaded yet?
But I see the reload activities in dmesg:
 ... apparmor="STATUS" operation="profile_replace" ...

A manual reload while in this state shows:
  info="same as current profile, skipping"

So it clearly is loaded correctly.

Analyzing the stack on that shows that it gets back up to "qemuDomainSnapshotCreateDiskActive" without triggering the issue.
At this point it looped over the involved disks and called qemuDomainSnapshotCreateSingleDiskActive which led to the adding of the profile rules.

Then there it starts a async monitor job.
And the sync on that then triggers the denies.
  ret = qemuMonitorTransaction(priv->mon, &actions);

We know this is the qemu driver and the domain pointer is my domain, the async flag is: QEMU_ASYNC_JOB_SNAPSHOT

This command is
a) what triggers the denials
b) failing and due to that later invoking the restore of the original profile

What is submitted is the actual snapshot command to qemu:
in qemuMonitorJSONCommandWithFd:
(gdb) printf "%s\n", cmdbuf.content
{
  "execute": "transaction",
  "arguments": {
    "actions": [
      {
        "type": "blockdev-snapshot-sync",
        "data": {
          "device": "drive-virtio-disk2",
          "snapshot-file": "/var/lib/libvirt/images/eoan-disk1.snapshot2.qcow",
          "format": "qcow2"
        }
      },
      {
        "type": "blockdev-snapshot-sync",
        "data": {
          "device": "drive-virtio-disk3",
          "snapshot-file": "/var/lib/libvirt/images/eoan-disk2.snapshot1.qcow",
          "format": "qcow2"
        }
      }
    ]
  },
  "id": "libvirt-32"
}

Hmm, I'm struggling here:
1. the profile with proper rules is loaded
2. the rule is 'rwk'
3. the denial is for read which 'r' should cover
4. the paths of rule and denial are identical
5. the reported profile that blocks is the profile that we extended

I'm missing something ...