Comment 27 for bug 1719579
Revision history for this message
| bugproxy (bugproxy) wrote Comment bridged from LTC Bugzilla | #27 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
------- Comment From <email address hidden> 2019-01-23 23:48 EDT-------
(In reply to comment #68)
> TBH - I haven't taken the former comment as a call for further action.
> It was more of a summary how docs and output could be better.
>
> Let me answer:
>
> 1. document that --bypass-cache would help
>
> Yeah it might be nice, but then it is just such a general thing.
> It only affects apparmor users (not all libvirt users).
> It only affects /tmp wi
> I wonder how such a hint might look like.
> Checking the doc there is a Note on disk corruption for virsh restore -
> maybe there as another Note entry.
> But I'm still not all in for this.
Okay, fine.
>
> 2. on older releases "error out or warn in Libvirt when performing save in
> denial paths"
>
> It is not really possible to predetect and differentiate if such a denial
> was the reason.
> Looking into the future I think we might use per-guest overrides.
>
> I was thinking on that more, the fact that all other but /tmp (for the
> explicit deny) just work, like:
> $ virsh save xenial-
> $ virsh restore /var/anythingbu
> That annoys me a lot.
>
> I'd suggest otherwise, we keep the past as it is without modifying man pages
> or anything like it (after all it is no regression I can SRU and a very
> special case choosing /tmp only).
> But I want to make it better thinking forward.
> I thought about it again and again, and revisited the old bug that added
> those deny rules.
> I think it is time to take them out in the next release.
Agree with you on this.
>
> That would mean it would generally work, and even if there is a deny it
> would at least be in the log.
> See also:
> - https:/
> - https:/
>
> I think the old assumptions don't hold true.
> So for the current and stable-releases we keep it as is, to not regress
> anyone (with too much logs).
> But forward I'd drop the deny rules and then all of this (and similar things
> where users WANT e.g. images in /tmp) would work.
ACK
>
> Part of it would be to check (way more modern and recent) openstack that it
> no more has those issues and if it has as part of the fix look for something
> better e.g. adapt how openstack sets the ceph config to no more trigger /tmp
> /tmp/var access.
>
> There are also rules like owner /tmp/pulse-*/ rw, in the meantime which get
> trumped by the deny.
> TL;DR - taking out the deny and making the save/restore case of this bug no
> more a special case would be much better IMHO.
>
> If you are ok with that I'd create a new bug to:
> 1. take out the deny rules to /tmp early in Ubuntu 18.10
Yes, I am okay on it.
> 2. do an analysis with recent openstack+ceph if they still trigger access
> there
well, I am not working on openstack and ceph. so could not comment on it.
>
> So are you ok with that approach?
:+1: for 1
>
> P.S. If you really really (...really*) want/need a man page entry for this
> special case we could work something out, but I think that would not qualify
> as an SRU [1] so thinking forward is much better anyway.
As you have mentioned earlier, I think it is not necessary.
>
> [1]: https:/
Thank you for your support.