[Bug 691590] Re: libvirt restore exactly the old ownership of images

[Robie Basak]

The key SRU user impact justification I wanted I found in Soren's
comment 27 - thank you.

Can I request that both the "filesystem supporting xattr" and "no
filesystem xattr support" cases be verified for expected behaviour
please?

Since we're changing behaviour I'm also concerned that this is high risk
of regression for some use case we haven't considered where the previous
behaviour is being depended upon. Thoughts on how to mitigate this would
be appreciated. I appreciate that Christian has already come up with and
tested a variety of use cases here - how comprehensive do you think
these are when compared to "weird" things users might be doing?

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/691590

Title:
  libvirt restore exactly the old ownership of images

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Focal:
  Fix Committed

Bug description:
  [Impact]

   * A rather old bug which could have been solved much sooner. Attr support 
     was disabled way back in time for triggering some test issues. Since 
     then the test issues and also many more rough edges of ATTR support have 
     been fixed.

   * This change shall enable attr support again which allows libvirt to 
     remember and carry ownership information on image files as extended 
     attributes.

  [Test Case]

   * Prepare a guest that you can start/stop e.g. with uvtool-libvirt
   * Own the image by anything other than root:root
   * Start the guest (ownership will change to the user the guest runs as)
   * Stop the guest:
     - fail: will set root:root to the images effectively stealing them
     - correct: remembers the old ownership and restores that

  [Regression Potential]

   * This mostly influences DAC control of files, which is exactly what we 
     want to fix. There are a few lifecycle tasks which now also have to 
     carry labels e.g. on any image handling. I don't expect regressions, but 
     this is the place to look out for.
   * The behavior on File systems unable to XATTR matches that of the 
     formerly disable feature, so on those cases where it has no positive 
     change it will have no change at all.

  [Other Info]
   
   * Technically we could backport this into all releases, but while I find 
     it right to fix in Focal OTOH Bionic and even more so Xenial really are 
     even "more stable" after their time in the field. Users either have 
     adapted already or even rely/expect the semi-broken behavior. Therefore 
     this is only targetting Focal intentionally.

   * (very) worst case one can set the FS the images are on to "nouser_xattr"
     as mount option.

  
  ---

  Natty (and it was also the same on Maverick, IIRC).

  When you assign an ISO to a VM, libvirt will take over onwership of
  the ISO. This creates problems if the ISO is updated.

  For example, I am daily updating the Natty server ISOs, and running
  tests on them via KVM (all automated). The ISO updates will fail
  because libvirt chowns them.

  I see no reason for this: libvirt only needs the ISO as input.

  WORKAROUND:
    edit /etc/libvirt/qemu.conf, change 'dynamic_ownership = 0', restart qemu/KVM.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/691590/+subscriptions