Comment 11 for bug 1813662

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.