------- Comment From sthou...@in.ibm.com 2018-04-09 09:03 EDT-------
(In reply to comment #64)
> (In reply to comment #61)
> > 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
> > profile="/usr/sbin/libvirtd"
> > 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/bionic-test.save --verbose
> > Guest is shut-off and I have
> > -rw------- 1 root root 527808329 Feb 19 12:34 /var/tmp/bionic-test.save
> > 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/bionic-test.save
> > Domain restored from /var/tmp/bionic-test.save
> >
> > To quote jdstrand from bug 1403648:
> > "We should not allow access to /tmp and /var/tmp as that breaks application
> > isolation."
> >
> > That said we are in the following situation:
> > 1. /tmp and /var/tmp are not allowed to be read (apparmor default for app
> > isolation)
> > 2. read denies there are silenced via explicit denies in
> > /etc/apparmor.d/abstractions/libvirt-qemu
> > 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.
>
> Okay, Agreed.
>
> > 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.
>
> Anyway, when restore is denied in turn it would make save as useless is my
> point here.
> let's document it in man page about --bypass-cache would help
>
> >
> > 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?
>
> if it is possible to error out or warn in Libvirt when performing save in
> denial paths that this
> would fail on restore by apparmor, then it would be a proper way.
> >
> > 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).
>
> Thank you for detailed explanation :+1:
Distro team,
Is there any update based on the previous update we posted. ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1719579
Title:
[Ubuntu 18.04] [libvirt] virsh restore fails from state file saved in
/var/tmp folder using virsh save
Status in The Ubuntu-power-systems project:
Fix Released
Status in apparmor package in Ubuntu:
Invalid
Status in libvirt package in Ubuntu:
Fix Released
Bug description:
== Comment: #1 - SEETEENA THOUFEEK <sthou...@in.ibm.com> - 2017-01-17
00:09:16 ==
Bala, Please mail me the machine information.
== Comment: #3 - SEETEENA THOUFEEK <sthou...@in.ibm.com> - 2017-01-17
02:14:06 ==
2017-01-16 12:09:37.707+0000: 7024: info :
virSecurityDACRestoreFileLabelInternal:388 : Restoring DAC user and group on
'/var/tmp/bala'
2017-01-16 12:09:37.707+0000: 7024: info :
virSecurityDACSetOwnershipInternal:290 : Setting DAC user and group on
'/var/tmp/bala' to '0:0'
2017-01-16 12:09:37.707+0000: 7024: warning : qemuDomainSaveImageStartVM:6750
: failed to restore save state label on /var/tmp/bala
2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x3fff4ca62b00
2017-01-16 12:09:37.707+0000: 7024: debug : qemuDomainObjEndAsyncJob:1848 :
Stopping async job: start (vm=0x3fff4ca535c0 name=virt-tests-vm1-bala)
2017-01-16 12:09:37.707+0000: 7024: info : virObjectRef:296 : OBJECT_REF:
obj=0x3fff4ca62b00
2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x3fff4ca62b00
2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x3fff4ca535c0
2017-01-16 12:09:37.707+0000: 7024: debug : virThreadJobClear:121 : Thread
7024 (virNetServerHandleJob) finished job remoteDispatchDomainRestore with
ret=-1
2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x3fff7c002c10
2017-01-16 12:09:37.707+0000: 7024: debug : virNetServerProgramSendError:153
: prog=536903814 ver=1 proc=54 type=1 serial=4 msg=0x100133d2590
rerr=0x3fffa59be3c0
2017-01-16 12:09:37.707+0000: 7024: debug : virNetMessageEncodePayload:376 :
Encode length as 172
2017-01-16 12:09:37.707+0000: 7024: debug :
virNetServerClientSendMessageLocked:1399 : msg=0x100133d2590 proc=54 len=172
offset=0
2017-01-16 12:09:37.707+0000: 7024: info :
virNetServerClientSendMessageLocked:1407 : RPC_SERVER_CLIENT_MSG_TX_QUEUE:
client=0x100133d23c0 len=172 prog=536903814 vers=1 proc=54 type=1 status=1
serial=4
2017-01-16 12:09:37.707+0000: 7024: debug :
virNetServerClientCalculateHandleMode:157 : tls=(nil) hs=-1, rx=0x100133d0670
tx=0x100133d2590
2017-01-16 12:09:37.707+0000: 7024: debug :
virNetServerClientCalculateHandleMode:192 : mode=3
2017-01-16 12:09:37.707+0000: 7024: info : virEventPollUpdateHandle:152 :
EVENT_POLL_UPDATE_HANDLE: watch=417 events=3
2017-01-16 12:09:37.707+0000: 7024: debug : virEventPollInterruptLocked:727 :
Interrupting
2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x3fff7c002c10
2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x100133caea0
2017-01-16 12:09:37.707+0000: 7024: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x100133d23c0
.
2017-01-16 12:14:28.445+0000: 7019: info : qemuMonitorJSONIOProcessLine:201 :
QEMU_MONITOR_RECV_EVENT: mon=0x3fff94004d90 event={"timestamp": {"seconds":
1484568868, "microseconds": 444620}, "event": "MIGRATION", "data": {"status":
"failed"}}
2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorJSONIOProcessEvent:147
: mon=0x3fff94004d90 obj=0x100133b5670
2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToString:1762 :
object=0x100133a8000
2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToStringOne:1691 :
object=0x100133a8000 type=0 gen=0x100133d1160
2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToStringOne:1691 :
object=0x100133d2a80 type=2 gen=0x100133d1160
2017-01-16 12:14:28.445+0000: 7019: debug : virJSONValueToString:1795 :
result={"status":"failed"}
2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorEmitEvent:1218 :
mon=0x3fff94004d90 event=MIGRATION
2017-01-16 12:14:28.445+0000: 7019: info : virObjectRef:296 : OBJECT_REF:
obj=0x3fff94004d90
2017-01-16 12:14:28.445+0000: 7019: debug : qemuProcessHandleEvent:629 :
vm=0x3fff4ca535c0
2017-01-16 12:14:28.445+0000: 7019: info : virObjectNew:202 : OBJECT_NEW:
obj=0x100133d2870 classname=virDomainQemuMonitorEvent
2017-01-16 12:14:28.445+0000: 7019: debug : virObjectEventNew:645 :
obj=0x100133d2870
2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x100133d2870
2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:261 :
OBJECT_DISPOSE: obj=0x100133d2870
2017-01-16 12:14:28.445+0000: 7019: debug :
virDomainQemuMonitorEventDispose:477 : obj=0x100133d2870
2017-01-16 12:14:28.445+0000: 7019: debug : virObjectEventDispose:121 :
obj=0x100133d2870
2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x3fff94004d90
2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorJSONIOProcessEvent:172
: handle MIGRATION handler=0x3fff9d7247e0 data=0x100133a8000
2017-01-16 12:14:28.445+0000: 7019: debug :
qemuMonitorEmitMigrationStatus:1488 : mon=0x3fff94004d90, status=failed
2017-01-16 12:14:28.445+0000: 7019: info : virObjectRef:296 : OBJECT_REF:
obj=0x3fff94004d90
2017-01-16 12:14:28.445+0000: 7019: debug :
qemuProcessHandleMigrationStatus:1502 : Migration of domain 0x3fff4ca535c0
virt-tests-vm1-bala changed state to failed
2017-01-16 12:14:28.445+0000: 7019: info : virObjectUnref:259 : OBJECT_UNREF:
obj=0x3fff94004d90
2017-01-16 12:14:28.445+0000: 7019: debug : qemuMonitorJSONIOProcess:255 :
Total used 232 bytes out of 232 available in buffer
2017-01-16 12:14:28.445+0000: 7019: info : virEventPollUpdateHandle:152 :
EVENT_POLL_UPDATE_HANDLE: watch=430 events=13
2017-01-16 12:14:28.445+0000: 7023: error : qemuMigrationCheckJobStatus:2641
: operation failed: job: unexpectedly failed
this is an apparmor issue and there is no libvirt bug here.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1719579/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
