* Availability: package is in universe [1]
* Rationale: This package helps achieve blueprint [2]. It is useful to users of the Ubuntu HVM instances types on EC2, other EC2 and UEC instance types where the user cannot access the instance, and users of UEC images outside UEC/EC2.
* Security: There is very little security concern for this package. It builds function into the initramfs.
* Quality Assurance: Ubuntu bugs are filed at [3]. This is not a debian package.
* Dependencies: all build dependencies are in main
* Standards compliance: The package implements a very standard initramfs-tools plugin
* Maintenance: This is a Ubuntu only package, and will require maintenance by the Ubuntu server team. However, it is very small and is not expected to require much effort to maintain.
* Background information:
The cloud-initramfs-tools package provides 2 binary packages:
* cloud-initramfs-growroot will automatically resize the root partition on first boot of an instance. In many cloud environments, the user can specify how large they would like the disk to be at launch time. This initramfs plugin will re-write the partition table of the root filesystem so that it utilizes available space. It is necessary to avoid a require reboot to unmount the rootfs so that the kernel will re-read the partition table.
* cloud-initramfs-rescuevol will boot off of a volume that is labeled "RESCUE_VOL" if it is present on boot. This allows a user of an instance to potentially save/repair an instance that is unreachable by attaching a new disk and rebooting.
--
[1] https://launchpad.net/ubuntu/+source/cloud-initramfs-tools
[2] https://blueprints.launchpad.net/ubuntu/+spec/cloud-server-n-cloud-images
[3] https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools
This is a place holder bug for getting cloud-initramfs-tools into main.
It will be updated with thorough description later.
cloud-initramfs
cloud-initramfs
I see no sane problems with this. If an attacker is in a position to be attaching volumes and rebooting, there are all kinds of other insane stuff they could do too.
The only thing I see as remotely "funny" would be what you outlined in email -- if they somehow have access to the label of an attached device and can trigger a reboot. But ... again, this falls into an existing vulnerability category.
I don't think it's a problem at all.
+1