Interesting indeed.
I remember the patch to restore file ownership, and at least in the cases I
looked at it worked fine.
I'm using the normal Ubuntu libvirt in Focal
ii libvirt-daemon 6.0.0-0ubuntu8.1 amd64Virtualization daemon
That is built without attr support as Soren outlined, a
Extra comment to not be lost - thanks Soren for the hint.
** Changed in: libvirt (Ubuntu)
Assignee: Phillip Susi (psusi) => Christian Ehrhardt (paelzer)
** Changed in: libvirt (Ubuntu)
Importance: Low => Medium
** Tags added: libvirt-20.10
--
You received this bug notification
Note, this will be part of the libvirt merge (including all sorts of
regression checks) which will be late July/early August.
** Changed in: libvirt (Ubuntu)
Status: Triaged => In Progress
** Summary changed:
- libvirt should not take ownership of ISO images
+ libvirt restore exactly the
It's exceptionally frustrating.
It's been a while since it was solved upstream such that when a domain
is terminated, the image ownership gets restored to what it was when the
domain was launched. However, the way it tracks the original ownership
is by storing it in xattr's of the image... but
Launchpad has imported 5 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=568935.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
This really feels like a serious security bug. The whole point of
running qemu as non root is to prevent it from accessing files that you
haven't given it permission to. By blindly chowning files to the qemu
user, you allow for the user who is given permission to run virtual
machines to start
This really feels like a serious security bug. The whole point of
running qemu as non root is to prevent it from accessing files that you
haven't given it permission to. By blindly chowning files to the qemu
user, you allow for the user who is given permission to run virtual
machines to start
** Description changed:
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
** Description changed:
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
** Changed in: libvirt (Ubuntu)
Status: Triaged = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
To manage
See https://www.redhat.com/archives/libvir-
list/2011-October/msg00104.html and https://www.redhat.com/archives
/libvir-list/2011-October/msg00110.html for the upstream response. The
first message describes the proper fix (switching from chown to acls in
the dac security code). The second
yes, I can set a readonly mount. Will have it set in a few. Thank you,
Serge.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in Ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO
See https://www.redhat.com/archives/libvir-
list/2011-October/msg00104.html and https://www.redhat.com/archives
/libvir-list/2011-October/msg00110.html for the upstream response. The
first message describes the proper fix (switching from chown to acls in
the dac security code). The second
yes, I can set a readonly mount. Will have it set in a few. Thank you,
Serge.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
To manage
Re-verified the bug and the patch, and sent the patch to the upstream
mailing list:
https://www.redhat.com/archives/libvir-list/2011-September/msg00458.html
If upstream rejects this, then I will mark the bug wontfix.
--
You received this bug notification because you are a member of Ubuntu
Re-verified the bug and the patch, and sent the patch to the upstream
mailing list:
https://www.redhat.com/archives/libvir-list/2011-September/msg00458.html
If upstream rejects this, then I will mark the bug wontfix.
--
You received this bug notification because you are a member of Ubuntu
It seems the ISOs are hosed right now, I get a sudden reboot in the
basic package install. But -- as far as this bug is concerned -- the
ISOs ownership are maintained on the original owner.
Perfect, Serge.
--
You received this bug notification because you are a member of Ubuntu
Server Team,
It seems the ISOs are hosed right now, I get a sudden reboot in the
basic package install. But -- as far as this bug is concerned -- the
ISOs ownership are maintained on the original owner.
Perfect, Serge.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: Proposed patch to not chown isos
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/691590/+attachment/1774914/+files/debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
A package with the proposed fix is available for natty in ppa:serge-
hallyn/virt. If this does what you need, then we can proceed to talk to
the libvirt community.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
Thank you, Serge. Testing it now.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
--
Ubuntu-server-bugs mailing list
** Attachment added: Proposed patch to not chown isos
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/691590/+attachment/1774914/+files/debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
A package with the proposed fix is available for natty in ppa:serge-
hallyn/virt. If this does what you need, then we can proceed to talk to
the libvirt community.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Thank you, Serge. Testing it now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
--
ubuntu-bugs mailing list
So does that suffice for your needs?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
--
Ubuntu-server-bugs mailing
Actually, no... theonly change is the owner got to be root, from
libvirt. I still am not convinced a read-only ISO has to be chown-ed to
the libvirt account.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
I intend to write a patch to make this behavior an option, and send it
to the libvirt list for comment.
** Changed in: libvirt (Ubuntu)
Status: New = Triaged
** Changed in: libvirt (Ubuntu)
Importance: Undecided = Low
--
You received this bug notification because you are a member of
** Bug watch added: Red Hat Bugzilla #568935
https://bugzilla.redhat.com/show_bug.cgi?id=568935
** Also affects: libvirt via
https://bugzilla.redhat.com/show_bug.cgi?id=568935
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of
So does that suffice for your needs?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
--
ubuntu-bugs mailing list
Actually, no... theonly change is the owner got to be root, from
libvirt. I still am not convinced a read-only ISO has to be chown-ed to
the libvirt account.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I intend to write a patch to make this behavior an option, and send it
to the libvirt list for comment.
** Changed in: libvirt (Ubuntu)
Status: New = Triaged
** Changed in: libvirt (Ubuntu)
Importance: Undecided = Low
--
You received this bug notification because you are a member of
** Bug watch added: Red Hat Bugzilla #568935
https://bugzilla.redhat.com/show_bug.cgi?id=568935
** Also affects: libvirt via
https://bugzilla.redhat.com/show_bug.cgi?id=568935
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of
A correction on the above I just tried with qemu.conf setting
user/group to root -- the ISO gets chown-ed to root:root, 0600.:
Actually, the permissions are kept as they were.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in
A correction on the above I just tried with qemu.conf setting
user/group to root -- the ISO gets chown-ed to root:root, 0600.:
Actually, the permissions are kept as they were.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This whole bug is about libvirt's DAC security driver. It will chown
files to the user that kvm runs as. On Ubuntu, this is the libvirt-
qemu:kvm user (adjustable via /etc/libvirt/qemu.conf). If you look at
the ISO file, its ownership should have been changed to this user. The
DAC security driver
This whole bug is about libvirt's DAC security driver. It will chown
files to the user that kvm runs as. On Ubuntu, this is the libvirt-
qemu:kvm user (adjustable via /etc/libvirt/qemu.conf). If you look at
the ISO file, its ownership should have been changed to this user. The
DAC security driver
@Clint: zsync does the same (writes the updated file to a temp, then
renames/unlinks/whatever -- did not check the source).
@Jamie: I just tried with qemu.conf setting user/group to root -- the
ISO gets chown-ed to root:root, 0600. So, no dice here. Nevertheless, my
whole point is it does not
** Tags added: iso-testing
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
--
Ubuntu-server-bugs mailing list
I don't think it would be safe at any rate to have the ISO images be
written to while kvm is reading them. Would it be ok to work around
this another way?
Perhaps the right way to update the ISOs is:
cp orig.iso new.iso
rsync -Pv mirror://updated_iso.iso new.iso
rm
Yes, this would work (as long as the process doing this move owns the
directory -- otherwise it is still an error 13). The whole point,
though, is that libvirt does not need to take ownership of a *read-only*
file.
At least it could revert the ownership when the VM is closed, if you
want to
Serge, from what I understand of rsync, it never writes directly to the
destination file, it will create a temporary hidden file and write to
that, then unlink/rename when the transfer is complete.
So the steps can just be
rsync rsync://mirror/file.iso orig.iso
it won't interfere at all with
** Tags added: iso-testing
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691590
Title:
libvirt should not take ownership of ISO images
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
I don't think it would be safe at any rate to have the ISO images be
written to while kvm is reading them. Would it be ok to work around
this another way?
Perhaps the right way to update the ISOs is:
cp orig.iso new.iso
rsync -Pv mirror://updated_iso.iso new.iso
rm
Yes, this would work (as long as the process doing this move owns the
directory -- otherwise it is still an error 13). The whole point,
though, is that libvirt does not need to take ownership of a *read-only*
file.
At least it could revert the ownership when the VM is closed, if you
want to
Serge, from what I understand of rsync, it never writes directly to the
destination file, it will create a temporary hidden file and write to
that, then unlink/rename when the transfer is complete.
So the steps can just be
rsync rsync://mirror/file.iso orig.iso
it won't interfere at all with
45 matches
Mail list logo
