Cannot build VM

[Jarl]

I run the most simple command and yet it fails:

$ LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 virt-builder ubuntu-18.04
[ 0.8] Downloading: http://libguestfs.org/download/builder/ubuntu-18.04.xz
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: create: flags = 0, handle = 0x56180ba4a700, program = virt-builder
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
[ 1.6] Planning how to build this image
[ 1.6] Uncompressing
[ 8.0] Opening the new disk
libguestfs: trace: set_verbose true
libguestfs: trace: set_verbose = 0
libguestfs: create: flags = 0, handle = 0x56180babc980, program = virt-builder
libguestfs: trace: set_network true
libguestfs: trace: set_network = 0
libguestfs: trace: add_drive "ubuntu-18.04.img" "format:raw" "cachemode:unsafe"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: max_disks
libguestfs: trace: max_disks = 255
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: version
libguestfs: trace: version = <struct guestfs_version = major: 1, minor: 38, release: 4, extra: , >
libguestfs: trace: get_backend
libguestfs: trace: get_backend = "direct"
libguestfs: launch: program=virt-builder
libguestfs: launch: version=1.38.4
libguestfs: launch: backend registered: unix
libguestfs: launch: backend registered: uml
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/tmp/libguestfsDT23Wh
libguestfs: launch: umask=0002
libguestfs: launch: euid=1000
libguestfs: trace: get_backend_setting "force_tcg"
libguestfs: trace: get_backend_setting = NULL (error)
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: begin building supermin appliance
libguestfs: run supermin
libguestfs: command: run: /usr/bin/supermin
libguestfs: command: run: \ --build
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --if-newer
libguestfs: command: run: \ --lock /var/tmp/.guestfs-1000/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
libguestfs: command: run: \ -o /var/tmp/.guestfs-1000/appliance.d
supermin: version: 5.1.19
supermin: package handler: debian/dpkg
supermin: acquiring lock on /var/tmp/.guestfs-1000/lock
supermin: build: /usr/lib/x86_64-linux-gnu/guestfs/supermin.d
supermin: reading the supermin appliance
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz type gzip base image (tar)
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/daemon.tar.gz type gzip base image (tar)
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/excludefiles type uncompressed excludefiles
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/hostfiles type uncompressed hostfiles
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/init.tar.gz type gzip base image (tar)
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages type uncompressed packages
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-hfsplus type uncompressed packages
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-reiserfs type uncompressed packages
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages-xfs type uncompressed packages
supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/udev-rules.tar.gz type gzip base image (tar)
supermin: mapping package names to installed packages
supermin: resolving full list of package dependencies
supermin: build: 227 packages, including dependencies
supermin: build: 10164 files
supermin: build: 6786 files, after matching excludefiles
supermin: build: 6789 files, after adding hostfiles
supermin: build: 6786 files, after removing unreadable files
supermin: build: 6789 files, after munging
supermin: kernel: looking for kernel using environment variables ...
supermin: kernel: looking for kernels in /lib/modules/*/vmlinuz ...
supermin: kernel: looking for kernels in /boot ...
supermin: kernel: kernel version of /boot/vmlinuz-4.18.0-13-generic = 4.18.0-13-generic (from filename)
supermin: kernel: picked modules path /lib/modules/4.18.0-13-generic
supermin: kernel: kernel version of /boot/vmlinuz-4.18.0-12-generic = 4.18.0-12-generic (from filename)
supermin: kernel: picked modules path /lib/modules/4.18.0-12-generic
supermin: kernel: kernel version of /boot/vmlinuz-4.13.0-38-generic.efi.signed = error, no modpath
supermin: kernel: kernel version of /boot/vmlinuz-4.13.0-38-generic = 4.13.0-38-generic (from filename)
supermin: kernel: picked modules path /lib/modules/4.13.0-38-generic
supermin: kernel: picked vmlinuz /boot/vmlinuz-4.18.0-13-generic
supermin: kernel: kernel_version 4.18.0-13-generic
supermin: kernel: modpath /lib/modules/4.18.0-13-generic
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.o7n720ze/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

If reporting bugs, run virt-builder with debugging enabled and include the
complete output:

  virt-builder -v -x [...]
libguestfs: trace: close
libguestfs: closing guestfs handle 0x56180babc980 (state 0)
libguestfs: command: run: rm
libguestfs: command: run: \ -rf /tmp/libguestfsDT23Wh
libguestfs: trace: close
libguestfs: closing guestfs handle 0x56180ba4a700 (state 0)

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: libguestfs-tools 1:1.38.4-1ubuntu2
ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
Uname: Linux 4.18.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
CurrentDesktop: KDE
Date: Mon Jan 28 22:04:49 2019
InstallationDate: Installed on 2016-01-08 (1116 days ago)
InstallationMedia: Kubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: libguestfs
UpgradeStatus: Upgraded to cosmic on 2018-10-23 (97 days ago)

[Richard Jones (rjones-redhat)]

This looks like an instance of our old favourite:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725

[Jarl (jarl-dk)]

@Richard Jones: I don't quite agree. It is not reported on the same package. This bug is not about requesting read-permission on the kernel (that may be one solution though). This bug is about virt-builder not working on ubuntu (where kernels are not readable by non-root users).

I agree though that this bug has emerged as a consequence of the sane decision that kernels should not be readable.
I also agree that a temporary workaround (until this bug is fixed) is that root user could make the kernels readable by others.

[Richard Jones (rjones-redhat)]

The problem is that the kernel isn't readable by non-root for
voodoo reasons. (I don't agree this is a sane configuration)

This affects several programs and needs to be fixed either by
making the kernels readable, or by having Ubuntu developers
change the libguestfs packaging so it triggers chmod +r on the
kernel every time the kernel is upgraded.

[Jarl (jarl-dk)]

I tend to agree with you and the discussion on the other bug that I don't see that preventing read-access to the running kernel gives any security at all.

On the other hand I don't see any reason that specifically virt-bulider need that read-access and should/could be designed to work without that read-access.

I don't know much of the design of virt-builder and wonder why does virt-builder need read-access to the running kernel at all? At first glance this seems like a bad software design. I don't think that all the other tools for building VMs (vagrant vmware, virtualbox, obsolete vmbuilder) need that.

Anyway, if the kernel team insists on blocking read-access, which it seems like they do, I think a more proper solution design would be to make a small helper program (shipped with this package) that can read the running kernel via SUID on that small helper program that does only one thing (read the kernel).

[Richard Jones (rjones-redhat)]

It's how it works: http://libguestfs.org/guestfs-internals.1.html#architecture

It doesn't need access to the running kernel (nor to live kernel memory),
but to a kernel image, and the kernel image in /boot is convenient for
that purpose. Anyway this works fine on every other Linux distro except
Ubuntu (even Debian) so IMO it's still an Ubuntu problem that can only be
fixed by Ubuntu developers.

[Jarl (jarl-dk)]

OK. Thanks for the link and explanation. So it doesn't have to be the exact image of the kernel that is running? just a reasonable image?

If it is not strictly necessary ot be the image of the running kernel, I see a better solution to this bug, which I also consider a better design of virt-builder:
Put a/the kernel image into the file that is downloaded, i.e. http://libguestfs.org/download/builder/ubuntu-18.04.xz, and use that image file when building an OS/VM because apparently virt-builder cannot count on kernel images being available on all supported operating systems (hereamong Ubuntu/Debian).

[Richard Jones (rjones-redhat)]

You can choose arbitrary kernels by setting the SUPERMIN_* environment
variables. See:
http://libguestfs.org/supermin.1.html#ENVIRONMENT-VARIABLES
http://libguestfs.org/guestfs-faq.1.html#how-can-i-compile-and-install-libguestfs-if-my-distro-doesnt-have-new-enough-qemu-supermin-kernel

There's already a kernel inside http://libguestfs.org/download/builder/ubuntu-18.04.xz
but how would you access it without libguestfs? And it wouldn't work
for non-Linux cases (we support Windows too).

[Hilko Bengen (bengen)]

* Jarl:

> @Richard Jones: I don't quite agree. It is not reported on the same
> package. This bug is not about requesting read-permission on the
> kernel (that may be one solution though). This bug is about
> virt-builder not working on ubuntu (where kernels are not readable by
> non-root users).

It does not really matter what you would like the bug or its solution to
be about:

Any user who wants to run anything that uses libguestfs (such as
virt-builder) needs to be able to read the kernel image which has not
been possible in the default Ubuntu installation for some time.

The Ubuntu community puts little effort into libguestfs package
maintenance except for copying whatever version from Debian and appliyng
what looks like mechanically applied patches. Which is fine, but I don't
expect anything to change.

That is unless somebody:

(1) comes up with a change to the libguestfs package that changes
    kernel image permissions as outlined by Richard and
(2) gets me to include said change in the Debian package (which I'll
    probably be willing to do.)

I have been maintaining the libguestfs package in Debian since 2011 and
I don't remember how often I have deleted notifications about these
issues in the last few years. Judging from how annoyed I have become at
this issue, there seems to be a real opportunity for anybody reading
this to make a real difference by making lots of Ubuntu users happier.

Cheers,
-Hilko

[jarl (jarl-redhat-bugs)]

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.

[Jarl (jarl-dk)]

@Hilko. First of all thank you very much for putting your time into maintaining packages. This is highly appreciated.
Secondly, I don't consider this issue a packaging issue (neither on the linux nor the libguestfs package). Even though it is an issue that has emerged from the ubuntu/debian decision that system kernel images shall not be readable by non-root users, I consider it an issue of the libguestfs software. Therefore I have opened a bug report on the libguestfs bug-system: https://bugzilla.redhat.com/show_bug.cgi?id=1670790

[rjones (rjones-redhat-bugs)]

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.

[ptoscano (ptoscano-redhat-bugs)]

(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.

[Hilko Bengen (bengen)]

* Jarl:

> @Hilko. First of all thank you very much for putting your time into
> maintaining packages. This is highly appreciated.

I was not fishing for thank-yous, I'm offering to get an Ubuntu-specific
problem worked around. Take it or leave it.

Instead of insisting that you know all there is to know about the issue,
how about providing that patch with the workaround we suggested? Or, how
about finding somebody to work on such a patch?

> I consider it an issue of the libguestfs software.

I suppose that you were not aware that you were exchanging messages with
the main upstream author then?

Cheers,
-Hilko

[jarl (jarl-redhat-bugs)]

@Pino: Thanks for emphasizing that only Ubuntu (and derivatives) is affected. I should have researched myself, sorry.

Thank you for feedback on my ideas on solving the problem, I can see that change in libguestfs funcitonality is more complex than I thought. At least my ideas have now been reviewed by the right people.

I completely agree with you that idea 2; a suid binary is not a good
idea. I will read up the technical documentation to understand the
problems with idea 1, thanks.

@maintainers (hereamong Richard Jones):

I understand that you have requested a change (revert) in the linux package on ubuntu so read permission is not restricted to root user (https://bugs.launchpad.net/bugs/759725) as this has broken the libguestfs functionality on ubuntu.
I also understand that there is no real security reasons for restricting read-access to the system kernels.

However it seems that the kernel maintainers are still decided to not
open up for read-permission on kernel images (rationally or not). To
help users (those who compile and install them self) know what they
need to do in order to make it work on ubuntu I wonder if it was worth
adding these steps (change file permission on kernel images) in the
documentation. It could be added on
http://libguestfs.org/guestfs-building.1.html. Either in section
"BUILDING FROM TARBALLS" or "INSTALLING" and eventually mention that
this is due to the bug https://bugs.launchpad.net/bugs/759725 that you
have reported. Maybe even better to actually perform this file
permission change during "make install" on Ubuntu only of course.

Just another idea in the hope of improving the end-user experience.

[Jarl (jarl-dk)]

@Hilko:

> > @Hilko. First of all thank you very much for putting your time into
> > maintaining packages. This is highly appreciated.

> I was not fishing for thank-yous, I'm offering to get an Ubuntu-specific
> problem worked around. Take it or leave it.

I am sorry. I didn't mean to offend you. Yes, there are several workarounds. It's not clear to me exactly which one you mean. For now I just run virt-builder with sudo.

> how about providing that patch with the workaround we suggested?

I may take a look at working on a patch. I have cloned libguestfs, but can you point me in the right direction libguestfs package? When I open https://packages.ubuntu.com/source/trusty/libguestfs and follow the links under "Debian Source Repository", the page shows that "The alioth.debian.org service is discontinued".

> I suppose that you were not aware that you were exchanging messages with
the main upstream author then?

You are absolutely right, I was not aware of that. That is good news to me, my ideas have been reviewed and considered by the right people. My intention of opening https://bugzilla.redhat.com/show_bug.cgi?id=1670790 was exactly to reach the upstream developers, I was not aware that I've reached them already :-)

[Hilko Bengen (bengen)]

* Jarl:

>> how about providing that patch with the workaround we suggested?
>
> I may take a look at working on a patch. I have cloned libguestfs, but
> can you point me in the right direction libguestfs package? When I open
> https://packages.ubuntu.com/source/trusty/libguestfs
> and follow the links under "Debian Source Repository", the page shows
> that "The alioth.debian.org service is discontinued".

If you look at the next stable Ubuntu release "disco"
(<https://packages.ubuntu.com/source/disco/libguestfs>), you'll be
directed to <https://salsa.debian.org/libvirt-team/libguestfs>.

Here's a bit of unsolicited advice regarding a possible patch: You'll
need to add a mechanism to make kernel images readable.

This means doing more than a "chmod 644 /boot/vmlinuz*" at libguestfs0
post-installation time because any kernel image installed after the
libguestfs0 package would not be affected. Instead of chmod, please use
dpkg-statoverride(1). Using a dpkg-trigger(1) that fires on kernel
installation or removal seems like a good idea. Also you should add code
to ask users whether they want this mechanism to be activated, using
debconf(1). After all, read-only kernel images are percieved as a
security measure by the Ubuntu project.

Cheers,
-Hilko

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mark - Syminet (mark-syminet)]

Hilko, you probably know this but it looks like in the original thread here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725

...that this could be fixed thusly:

To have this automatically happen with each new kernel, create /etc/kernel/postinst.d/statoverride:

  #!/bin/sh
  version="$1"
  # passing the kernel version is required
  [ -z "${version}" ] && exit 0
  dpkg-statoverride --add root root 0644 /boot/vmlinux-${version} --update

...can libguestfs package ship that script? Or would that be a policy violation of some sort?

It looks like if upon installation short script could be placed in /etc/kernel/postinst.d/statoverride, along with a "chmod 0644 /boot/vmlinuz*", then all those annoying bugreports from ubuntu users should go away.

[Thiago Martins (martinx)]

BUG https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725 is super, ultra annoying and useless!

:-@

[Thiago Martins (martinx)]

I'm creating a file:

/etc/kernel/postinst.d/fix-damn-bug-759725 with:

---
#/bin/sh

# https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725

set -e
version="$1"
if [ -z "$version" ]; then
    exit 0
fi
exec dpkg-statoverride --update --add root root 0644 "/boot/vmlinuz-${version}"
---

As a workaround to BUG 759725 that MUST be fixed by Ubuntu.

[Philippe Ombredanne (pombredanne)]

Hiya, I was kindly wondering if there is an update on this?
I have naive suggestion:

what about creating a small optional package that has the dpkg-statoverride script and let users be responsible to install it or not install it?

That way, Ubuntu kernel maintainers wishes are respected, and users can have it their way too.

And everyone may be satisfied this way?

[Hilko Bengen (bengen)]

Quoting my message from more than 2 years ago:

> The Ubuntu community puts little effort into libguestfs package
> maintenance except for copying whatever version from Debian and appliyng
> what looks like mechanically applied patches. Which is fine, but I don't
> expect anything to change.
>
> That is unless somebody:
>
> (1) comes up with a change to the libguestfs package that changes
> kernel image permissions as outlined by Richard and
> (2) gets me to include said change in the Debian package (which I'll
> probably be willing to do.)

Since I posted this, I'm not aware to have received bug reports via Debian's BTS (https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libguestfs) containing such a patch or merge requests on Salsa (https://salsa.debian.org/libvirt-team/libguestfs).

[Philippe Ombredanne (pombredanne)]

FYI, this is the kind of wart this issue is forcing down on me and all my users:
https://github.com/nexB/extractcode/blob/aa5da29014ce4fbffca53c09689a2623e2b78196/src/extractcode/vmimage.py#L82

> def check_linux_kernel_is_readable():
> """
> Return True if the kernel executable file can be read. This is required by
> guestfish and libguestfs and this is an oddity mostly on Ubuntu.
> See:
> - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725
> - https://bugzilla.redhat.com/show_bug.cgi?id=1670790
> - https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662
> """

I would like to create a package that fix this issue.

Is this the correct way:

1. As sudo, create the file /etc/kernel/postinst.d/statoverride with this
content, devised by Kees Cook (@kees) in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725/comments/3 ::

    #!/bin/sh
    version="$1"
    # passing the kernel version is required
    [ -z "${version}" ] && exit 0
    dpkg-statoverride --update --add root root 0644 /boot/vmlinuz-${version}

2. Setup the exxecutable permissions::

    sudo chmod +x /etc/kernel/postinst.d/statoverride

And if yes, is this enough to create a package that adds this file?

[Philippe Ombredanne (pombredanne)]

I created this set of instructions in https://raw.githubusercontent.com/nexB/extractcode/main/README.rst

I would appreciate if someone could minimally validate if this is the correct way:

Adding support for VM images extraction
---------------------------------------

Adding support for VM images requires the manual installation of the
libguestfs-tools system package. This is suported only on Linux.
On Debian and Ubuntu you can use this command::

    sudo apt-get install libguestfs-tools

On Ubuntu only, an additional manual step is required as the kernel executable
file cannot be read by users as required by libguestfish.

Run this command as a temporary and immediate fix::

    sudo chmod 0644 /boot/vmlinuz-*
    for k in /boot/vmlinuz-*
        do sudo dpkg-statoverride --add --update root root 0644 /boot/vmlinuz-$k
    done

You likely want both this temporary fix and a more permanent fix; otherwise each
kernel update will revert to the default permissions and ExtractCode will stop
working for VM images extraction.

Therefore follow these instructions:

1. As sudo, create the file /etc/kernel/postinst.d/statoverride with this
content, devised by Kees Cook (@kees) in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725/comments/3 ::

    #!/bin/sh
    version="$1"
    # passing the kernel version is required
    [ -z "${version}" ] && exit 0
    dpkg-statoverride --update --add root root 0644 /boot/vmlinuz-${version}

2. Set executable permissions::

    sudo chmod +x /etc/kernel/postinst.d/statoverride

See also these links for a complete discussion:

    - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725
    - https://bugzilla.redhat.com/show_bug.cgi?id=1670790
    - https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662/comments/24

[Hilko Bengen (bengen)]

Hi Philippe,

sorry for the late reply.

> FYI, this is the kind of wart this issue is forcing down on me and all my users:
> https://github.com/nexB/extractcode/blob/aa5da29014ce4fbffca53c09689a2623e2b78196/src/extractcode/vmimage.py#L82
>
>> def check_linux_kernel_is_readable():
>> """
>> Return True if the kernel executable file can be read. This is required by
>> guestfish and libguestfs and this is an oddity mostly on Ubuntu.
>> See:
>> - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725
>> - https://bugzilla.redhat.com/show_bug.cgi?id=1670790
>> - https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662
>> """

Yeah, I am well aware… As far as I can recall, you may well be the first
person to come up with somewhat sensible/constructive approach to this
mess and I am sorry that I let your mail sit in my inbox for so long.

There are just a few implementation details that should be done
differntly, I'll comment inline:

> I would like to create a package that fix this issue.

Why not add the hack in one of the libguestfs packages themselves? I
think that libguestfs0 would be the right choice. I'd be happy to
include this into the libguestfs package under two conditions:

- The changes are Ubuntu-specific.
- The changes have been tested.

> Is this the correct way:
>
> 1. As sudo, create the file /etc/kernel/postinst.d/statoverride with this
> content, devised by Kees Cook (@kees) in
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725/comments/3 ::
>
> #!/bin/sh
> version="$1"
> # passing the kernel version is required
> [ -z "${version}" ] && exit 0
> dpkg-statoverride --update --add root root 0644 /boot/vmlinuz-${version}

This looks reasonable. /etc/kernel/postinst.d/statoverride can simply be
added to a package (your package or libguestfs0), there's no need for
creating a script that does this at install time.

And instead of calling the script "statoverride", you should use
something that hints at the package name.

> 2. Setup the exxecutable permissions::
>
> sudo chmod +x /etc/kernel/postinst.d/statoverride

This is not necessary if you install that file into the package with the
right permissions in the first place.

> And if yes, is this enough to create a package that adds this file?

There are a few other issues to consider:

When a kernel image is removed, you should also remove the corresponding
statoverride entry (dpkg-statoverride remove $file), via a prerm or
postrm script.

The kernel postinst script does not help with kernel images that are
already installed when libguestfs0 (or your custom package) is added to
the system, so you'll need to call dpkg-statoverride for all kernel
images.

Similarly, users will expect that removing the package will remove the
statoverride entries, so you'll need a postrm script that does that for
all kernel images.

Cheers,
-Hilko