Thanks for the full dmesg.
It seems to me that:
"unable to set AppArmor profile 'libvirt-81b387d9-1dfc-4f55-8b98-0318f1f94442'"
means there is an issue in loading the profile after your change.

That matches:
 audit: type=1400 audit(1519028363.683:12417): apparmor="DENIED" 
operation="change_profile" info="label not found" error=-2 
name="libvirt-81b387d9-1dfc-4f55-8b98-0318f1f94442" pid=12949 comm="libvirtd"

It is not getting to the actual restore, it is failing when spawning the
guest to to the changes in the apparmor profile.

I tried to check what you hit:
$ virsh save bionic-test --file /var/tmp/ --verbose
Guest is shut-off and I have
-rw------- 1 root root 527808329 Feb 19 12:34 /var/tmp/
The restore hits the (silent) denial we discussed.
   #deny /tmp/{,**} r,                                                          
   #deny /var/tmp/{,**} r,
Changed the two lines above to a comment.
Then restored again, just worked:
$ virsh restore /var/tmp/
Domain restored from /var/tmp/

To quote jdstrand from bug 1403648:
"We should not allow access to /tmp and /var/tmp as that breaks application 

That said we are in the following situation:
1. /tmp and /var/tmp are not allowed to be read (apparmor default for app 
2. read denies there are silenced via explicit denies in 
3. I see your point:
3.1 on save libvirt writes to that place (libvirt is allowed to do so, while 
qemu is not)
3.2 on restore qemu wants to read it and is denied.

And you wonder about the asymetric behavior of 3.1 and 3.2.
I agree that it is somewhat unexpected, but wonder what would be better
1. We could also deny /var /tmp for the lbivirt daemon (which intentionally has 
a rather lenient apparmor profile). Then already on the save people would be 
denied, maybe for a new release - but not as an SRU to not break people relying 
on that access working.
2. And on the new release we already have the --bypass-cache fixes you referred 
to to get the restore working there as a workaround - so the benefit of 
preventing libvirt to access there isn't too big either. So forbidding the 
access on "save" for libvirt there would make that useless.

I'm unsure how to continue. To better brain-storm with you on how to
proceed do you have a clear preferred solution (other than the already
included bypass-cache fixes) or is it just "not nice in general" that
the denial should be consistent for save/restore?

Separate to the discussion above:
To find how your modified apparmor profile breaks your guest start you could 
share it - as I mentioned it worked for me right away (no need to restart 
libvirt after changing btw, the one we change it loaded on guest load).

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  [Ubuntu 18.04] [libvirt] virsh restore fails from state file saved in
  /var/tmp folder using virsh save

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to