Tails

#1 Updated by CyrilBrulebois 2020-01-11 00:28:20

Warning: You can safely pretend I don’t know anything about IUKs, upgrades, stack filesystems, and the like.

That being said, looking around in the devices, I’m seeing this after an upgrade:

• 4.2.1.squashfs
• filesystem.squashfs

while a pristine 4.2 image only has:

• filesystem.squashfs

Using unsquashfs as root on my host system, I’m getting similar contents in the resulting squashfs-root.{original,upgraded}/var/lib/gdm3:

drwxr-xr-x   4 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.original/var/lib/gdm3/
drwxr-xr-x   3 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.original/var/lib/gdm3/.local
drwxr-xr-x   3 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.original/var/lib/gdm3/.local/share
drwxr-xr-x   2 112     200          4096 Feb  9  2019 squashfs-root-filesystem.original/var/lib/gdm3/.local/share/applications
drwxr-xr-x   3 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.original/var/lib/gdm3/.config
drwxr-xr-x   2 112     200          4096 Feb  9  2019 squashfs-root-filesystem.original/var/lib/gdm3/.config/dconf
drwxr-xr-x   4 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.upgraded/var/lib/gdm3/
drwxr-xr-x   3 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.upgraded/var/lib/gdm3/.local
drwxr-xr-x   3 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.upgraded/var/lib/gdm3/.local/share
drwxr-xr-x   2 112     200          4096 Feb  9  2019 squashfs-root-filesystem.upgraded/var/lib/gdm3/.local/share/applications
drwxr-xr-x   3 112     200          4096 Jan  6 17:25 squashfs-root-filesystem.upgraded/var/lib/gdm3/.config
drwxr-xr-x   2 112     200          4096 Feb  9  2019 squashfs-root-filesystem.upgraded/var/lib/gdm3/.config/dconf

with 112:200 matching Debian-gdm:Debian-gdm in the Tails environment.

But the 4.2.1 which I guess ends up being put on top of the probably-untouched “main” filesystem.squashfs has:

drwxr-xr-x   4 root     root         4096 Jan  9 17:09 squashfs-root-4.2.1/var/lib/gdm3/
drwxr-xr-x   3 root     root         4096 Jan  9 17:09 squashfs-root-4.2.1/var/lib/gdm3/.local
drwxr-xr-x   2 root     root         4096 Jan  9 17:09 squashfs-root-4.2.1/var/lib/gdm3/.local/share
drwxr-xr-x   2 root     root         4096 Jan  9 17:09 squashfs-root-4.2.1/var/lib/gdm3/.config

which I guess shadows the permissions in the original filesystem, which in turn explains why GDM cannot open the X log file under the xorg subdirectory (that it has to create) under /var/lib/gdm3/.local/share. (As seen by setting a root password, and inspecting the reasons for the failed gdm.service unit.)

→ Fix the ownership issues, save the day?

#2 Updated by CyrilBrulebois 2020-01-11 00:36:06

(Same warning applies.)

And it seems Tails_amd64_4.2_to_4.2.1.iuk ships the file I was just looking at (seen under squashfs-root/overlay/live/4.2.1.squashfs after unsquashfs-ing the IUK), which seems to indicate fixing the IUK generation might be sufficient to unblock us, without having to tell users to fiddle with their un-automatically-upgradable 4.2 release?

#3 Updated by CyrilBrulebois 2020-01-11 01:41:17

(Same warning applies.)

Toying with config/chroot_local-includes/usr/src/iuk/lib/Tails/IUK.pm a little, particularly the create_squashfs_diff sub, it seems permissions are all fine with the mounting of the old and new root filesystems ($old_squashfs_mount and $new_squashfs_mount), also with the union mount ($union_mount).

But then, I’m seeing mksquashfs called, which happens to use those options:

method _build_mksquashfs_options () { [
    qw{-no-progress -noappend},
    qw{-all-root},
    qw{-comp xz -Xbcj x86 -b 1024K -Xdict-size 1024K},
]}

Looks to me -all-root is not our friend:

       -all-root
           make all files owned by root.

Looking at the history of iuk.git (since that was introduced before the merge into the main Tails repository), this dates back to:

commit b578872ba2167da7dbc106a9d20c88e523ab73b3
Author: intrigeri <intrigeri@boum.org>
Date:   Sun Nov 24 21:44:50 2019 +0000

    Start implementing IUK format v2 (<del><a class='issue tracker-2 status-3 priority-6 priority-default closed child' href='/code/issues/6876' title='Have the incremental upgrade process use less RAM'>Feature #6876</a></del>)

which seems consistent with a seemingly IUKv2-specific problem, which didn’t exist with IUKv1.

#4 Updated by CyrilBrulebois 2020-01-11 02:09:29

To verify, I’ve implemented these steps:

• dropped -all-root from mksquashfs options;
• dropped the last line, with compression options, so that I would get the default and quicker gzip compression (I was being a little impatient to know whether that would work);
• generated a new IUK from 4.2 to 4.2.1;
• extracted its /live/4.2.1.squashfs;
• tweaked the filesystem of the virtual machine that was already upgraded from 4.2 to 4.2.1, removing the broken /live/4.2.1.squashfs and replacing it with the brand new one extracted from the hacked IUK.

I’m seeing GDM start up just fine, Tails pretend it’s running 4.2.1 (looking at /etc/os-release), Tor Browser 9.0.4 running properly, etc.

#12 Updated by intrigeri 2020-01-11 09:03:57

Thank you for reviewing.

> Feel free to merge

Done.

> and to redo the IUKv2 dance.

Let’s coordinate this on XMPP.