Ensure default fstab options are sane and consistent across all images

[David Krauser]

The default fstab entries for ubuntu cloud images are:

LABEL=cloudimg-rootfs / ext4 defaults 0 0
LABEL=UEFI /boot/efi vfat defaults 0 0

These entries do not align with the defaults that we use elsewhere. We should decide on the defaults for fstab, and apply those consistently across all Ubuntu images.

--

quoted from ~xnox: the expect [these entries] to be:

LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1

[Robert C Jennings (rcj)]

Adding the cloud-images project so that a test can be added once this change lands in livecd-rootfs

[Joshua Powers (powersj)]

fwiw LP: #1912835 is tracking this and is already checked in:
https://git.launchpad.net/livecd-rootfs/commit/?id=33b7272a2331279b4c7aa8de73ed8a9069d0bd39

[Launchpad Janitor (janitor)]

This bug was fixed in the package livecd-rootfs - 2.715

---------------
livecd-rootfs (2.715) hirsute; urgency=medium

  [ Gauthier Jolly ]
  * ubuntu-cpc: change mount options in fstab to be align with defaults
    (LP: #1902103, LP: #1881006)

 -- Robert C Jennings <email address hidden> Tue, 02 Mar 2021 11:40:56 -0600

[Launchpad Janitor (janitor)]

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

[Robert C Jennings (rcj)]

@gjolly,

I've taken a look at the 'Where problems could occur' section of the SRU template and I'm concerned about the risk of regression for users altering mount options for the root file system.

My concerns involve the root filesystem line alone. I think 'discard' is nice-to-have but not worth the risk of breaking users that alter the line via code. I'm not convinced we should change the error option from 'continue' to 'remount-ro' in an SRU either; first because it could break automation that users have to change the line and second it changes behavior for error handling that could break user assumptions of systems already in production should they deploy with a newly built image and they'll be unlikely to have image qualification tests that trigger an IO error. I recommend SRU'ing without the changes for the root filesystem.

The change to the fstab line for the EFI file system pertains to a security improvement which I like to see. I think the risk is much lower that a user has automation changing mount options for this file system. The other risk is one of behavior. Will users have a non-root user accessing the EFI mountpoint and be broken by this change? Given the contents of the file system I don't believe it's unlikely most users would be accessing this directly. I believe the benefit from the change justifies the umask SRU.

[Gauthier Jolly (gjolly)]

@rcj thanks for your reply. Since we only want to SRU the umask change, I propose move the discussion under this bug[0] as it is only related to this particular change.

[0] https://bugs.launchpad.net/cloud-images/+bug/1881006

[Gauthier Jolly (gjolly)]

I will revert to the original description and move the SRU template to LP1881006.