Ensure default fstab options are sane and consistent across all images

Bug #1902103 reported by David Krauser on 2020-10-29
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-images
Undecided
Unassigned
curtin (Ubuntu)
Undecided
Unassigned
livecd-rootfs (Ubuntu)
Undecided
Unassigned
maas (Ubuntu)
Undecided
Unassigned
subiquity (Ubuntu)
Undecided
Unassigned
ubiquity (Ubuntu)
Undecided
Unassigned

Bug Description

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

Related branches

description: updated
Robert C Jennings (rcj) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in livecd-rootfs (Ubuntu):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in curtin (Ubuntu):
status: New → Confirmed
Changed in maas (Ubuntu):
status: New → Confirmed
Changed in subiquity (Ubuntu):
status: New → Confirmed
Changed in ubiquity (Ubuntu):
status: New → Confirmed
Gauthier Jolly (gjolly) on 2021-03-12
description: updated
Gauthier Jolly (gjolly) on 2021-03-12
description: updated
Robert C Jennings (rcj) on 2021-03-12
description: updated
description: updated
description: updated
Robert C Jennings (rcj) wrote :

@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) wrote :

@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) wrote :

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

description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers