| 2020-10-29 17:04:51 |
David Krauser |
bug |
|
|
added bug |
| 2020-10-29 17:05:27 |
David Krauser |
bug task added |
|
curtin (Ubuntu) |
|
| 2020-10-29 17:05:47 |
David Krauser |
bug task added |
|
maas (Ubuntu) |
|
| 2020-10-29 17:06:05 |
David Krauser |
bug task added |
|
subiquity (Ubuntu) |
|
| 2020-10-29 17:06:28 |
David Krauser |
bug task added |
|
ubiquity (Ubuntu) |
|
| 2020-10-29 17:06:49 |
David Krauser |
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 |
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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1 |
|
| 2021-01-07 17:00:42 |
Robert C Jennings |
bug task added |
|
cloud-images |
|
| 2021-03-02 14:23:10 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~gjolly/livecd-rootfs/+git/livecd-rootfs/+merge/398356 |
|
| 2021-03-03 02:25:27 |
Launchpad Janitor |
livecd-rootfs (Ubuntu): status |
New |
Fix Released |
|
| 2021-03-11 16:19:29 |
Launchpad Janitor |
curtin (Ubuntu): status |
New |
Confirmed |
|
| 2021-03-11 16:19:29 |
Launchpad Janitor |
maas (Ubuntu): status |
New |
Confirmed |
|
| 2021-03-11 16:19:29 |
Launchpad Janitor |
subiquity (Ubuntu): status |
New |
Confirmed |
|
| 2021-03-11 16:19:29 |
Launchpad Janitor |
ubiquity (Ubuntu): status |
New |
Confirmed |
|
| 2021-03-11 16:56:57 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2021-03-11 20:21:39 |
Ioanna Alifieraki |
bug |
|
|
added subscriber Ioanna Alifieraki |
| 2021-03-12 13:45:41 |
Gauthier Jolly |
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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1 |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[1]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Start a GCE or a KVM instance
* Check `/etc/fstab` content
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[2].
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] http://cloud-images.ubuntu.com/daily/server/focal/current/
[2] https://wiki.debian.org/SSDOptimization#WARNING
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1 |
|
| 2021-03-12 14:19:00 |
Gauthier Jolly |
description |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[1]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Start a GCE or a KVM instance
* Check `/etc/fstab` content
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[2].
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] http://cloud-images.ubuntu.com/daily/server/focal/current/
[2] https://wiki.debian.org/SSDOptimization#WARNING
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1 |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Start a GCE or a KVM instance
* Check `/etc/fstab` content
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
|
| 2021-03-12 14:29:59 |
Robert C Jennings |
description |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Start a GCE or a KVM instance
* Check `/etc/fstab` content
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Build an uefi image from the ubuntu-cpc project in livecd-rootfs
* Launch in KVM
* Check `/etc/fstab` content
* Check that mount options are reflected in 'mount' command output
* Ensure a non-root user can not access /boot/efi
* Check 'tune2fs -l $root_fs_dev' output for 'Error behavior' to match remount-ro
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
|
| 2021-03-12 14:31:02 |
Robert C Jennings |
description |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Build an uefi image from the ubuntu-cpc project in livecd-rootfs
* Launch in KVM
* Check `/etc/fstab` content
* Check that mount options are reflected in 'mount' command output
* Ensure a non-root user can not access /boot/efi
* Check 'tune2fs -l $root_fs_dev' output for 'Error behavior' to match remount-ro
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Build an uefi image from the ubuntu-cpc project in livecd-rootfs
* Launch in KVM
* Check `/etc/fstab` content
* Check that mount options are reflected in 'mount' command output
* Ensure a non-root user can not access /boot/efi
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
|
| 2021-03-12 14:33:39 |
Robert C Jennings |
description |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Build an uefi image from the ubuntu-cpc project in livecd-rootfs
* Launch in KVM
* Check `/etc/fstab` content
* Check that mount options are reflected in 'mount' command output
* Ensure a non-root user can not access /boot/efi
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Build an uefi image from the ubuntu-cpc project in livecd-rootfs
* Launch in KVM
* Check `/etc/fstab` content
* Check that mount options are reflected in 'mount' command output
* Ensure a non-root user can not access /boot/efi
* Check 'lsblk -D' output to see that there is a non-zero discard block size for the root device (this check may be imperfect, the goal is to check that discard from fstab is enabled if available from the underlying block device)
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
|
| 2021-03-17 14:59:53 |
Gauthier Jolly |
description |
[Impact]
* In cloud images, the ESP is currently mounted with default (0755)
permissions. This means anyone can read the ESP partition. This can
cause security issues as sensitive data might be put in this
partition[0]
* The root filesystem partition uses defaults mount options. In case
of filesystem error, it is safer to use `remount-ro`. Also for cloud
usage (where storage can be expensive) it makes sense to mount the
root filesystem with `discard`. This will also align cloud images
fstab with what we have elsewhere.
[Test Plan]
* Build an uefi image from the ubuntu-cpc project in livecd-rootfs
* Launch in KVM
* Check `/etc/fstab` content
* Check that mount options are reflected in 'mount' command output
* Ensure a non-root user can not access /boot/efi
* Check 'lsblk -D' output to see that there is a non-zero discard block size for the root device (this check may be imperfect, the goal is to check that discard from fstab is enabled if available from the underlying block device)
[Where problems could occur]
* Some users can have automation in place change those defaults. This
change might break their automation.
* `error=remount-ro` might create issues for certain user. Especially if
the filesystem superblock default was set to `error=continue`. For
those users, any error that was previously ignored will make the
filesystem read-only.
* `discard` parameter might have an impact on i/o throughput and reduce
read/write speed. Also some particular disk might have issues with
TRIM commands[1].
[original 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: I expect [these entries] to be:
LABEL=cloudimg-rootfs / ext4 discard,errors=remount-ro 0 1
LABEL=UEFI /boot/efi vfat umask=0077 0 1
[0] https://bugs.launchpad.net/cloud-images/+bug/1881006/comments/11
[1] https://wiki.debian.org/SSDOptimization#WARNING |
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 |
|
