Launchpad has imported 3 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1670790.
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 https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2019-01-30T11:21:37+00:00 jarl wrote: Description of problem: One of the fundamental values of virt-builder is that it does not require root privileges, that is state in the man page (http://libguestfs.org/virt-builder.1.html) as "nothing requires root privileges" However the current design/implementation has a prerequisite condition on the platform it is installed/running on. virt-builder requires that system kernel images are readable by non-root user. This prerequisite is not true for Debian and Ubuntu (and maybe others), hence the virt- builder does not work on these platforms. If Debian and Ubuntu should continue to be "supported" target platforms (and I suggest they should) then a change is needed for virt-builder. Version-Release number of selected component (if applicable): virt- builder 1.38.4 How reproducible: Every time! Steps to Reproduce: 1. $ LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 virt-builder ubuntu-18.04 Actual results: It fails with the following relevant output: cp: cannot open '/boot/vmlinuz-4.18.0-13-generic' for reading: Permission denied supermin: cp -p '/boot/vmlinuz-4.18.0-13-generic' '/var/tmp/.guestfs-1000/appliance.d.pqks7vg3/kernel': command failed, see earlier errors libguestfs: trace: launch = -1 (error) virt-builder: error: libguestfs error: /usr/bin/supermin exited with error status 1, see debug messages above Expected results: That an image named ubuntu-18.04.img was built. Workaround: Run the command with sudo. Proposals for resolution: Both proposals is an implementation of the idea of removing the prerequisite that a non-user has read access to system kernels. 1) Ship the kernel image(s) that are needed in the file that is downloaded anyway, i.e. http://libguestfs.org/download/builder/ubuntu-18.04.xz and use these instead of the kernels found on the OS. 2) Make a small helper program with SUID that reads the kernel image and use that program for that purpose only. Additional info: There is a bug report on the ubuntu package on https://bugs.launchpad.net/bugs/1813662 however I do not consider this issue a packaging problem. I think the issues should be resolved at it's roots, removing the requirement on the OS that the users has read-access to system kernel images. Reply at: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662/comments/10 ------------------------------------------------------------------------ On 2019-01-30T11:41:48+00:00 rjones wrote: This is a bug in Ubuntu, please see my and Hilko's extensive comments in https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662 I have nothing more to add. Reply at: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662/comments/12 ------------------------------------------------------------------------ On 2019-01-30T11:43:05+00:00 ptoscano wrote: (In reply to Jarl Friis from comment #0) This prerequisite is not true > for Debian and Ubuntu (and maybe others), hence the virt-builder does not > work on these platforms. If Debian and Ubuntu should continue to be > "supported" target platforms (and I suggest they should) then a change is > needed for virt-builder. Note that on Debian the vmlinuz files of the kernels have normal permissions (readable by anyone). This problem is specific to Ubuntu (and its derivatives). > 1) Ship the kernel image(s) that are needed in the file that is downloaded > anyway, i.e. http://libguestfs.org/download/builder/ubuntu-18.04.xz and use > these instead of the kernels found on the OS. Not doable, as you do not want to run an arbitrary kernel in an untrusted guest. > 2) Make a small helper program with SUID that reads the kernel image and use > that program for that purpose only. Please do take a look at our documentation: http://libguestfs.org/guestfs.3.html http://libguestfs.org/guestfs-internals.1.html (especially this) http://libguestfs.org/guestfs-faq.1.html The documentation should explain why the approach (1) you suggested cannot work. The approach (2) would be a workaround possibly worse than the problem itself; not to mention all the possible security issues of writing a suid binary, where code issues could cause bad CVEs. > There is a bug report on the ubuntu package on > https://bugs.launchpad.net/bugs/1813662 however I do not consider this issue > a packaging problem. I think the issues should be resolved at it's roots, > removing the requirement on the OS that the users has read-access to system > kernel images. That bug shows also how other packages were impacted by the change of permissions of the kernels. Considering that no other distro opted for this "security solution", and that it can be easily worked around in other ways, this is definitely an Ubuntu breakage. Reply at: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662/comments/13 ** Changed in: libguestfs Status: Unknown => Invalid ** Changed in: libguestfs Importance: Unknown => Undecided -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813662 Title: Cannot build VM To manage notifications about this bug go to: https://bugs.launchpad.net/libguestfs/+bug/1813662/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
