update-grub should not automatically configure booting from removable devices?

[Dave Martin]

Binary package hint: grub2

Affected: 1.98+20100804-4ubuntu6

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu maverick (development branch)
Release: 10.10
Codename: maverick

Totally by coincidence, I ran apt-get upgrade with a random card in a card reader.

The card had a maverick chroot on it (for a foreign architecture, so totally unbootable...)

Look what happens:

# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.35-22-generic
Found initrd image: /boot/initrd.img-2.6.35-22-generic
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
Found Ubuntu maverick (development branch) (10.10) on /dev/sdg2
done
# cat /sys/block/sdg/removable
1

Even more surprising, when I rebooted, grub popped up a boot menu giving me a chance to boot that removable device (which happened to be still plugged in).

I would question whether a removable device should be magically added to the boot device list when running update-grub.

For automated upgrades, magically adding random devices which aren't part of the installation to the boot list seems undesirable/unuseful at best. At worst, it's a security hole, though probably not very practical to exploit - there are ways an attacker could trick a naive user into setting up a removable device with a poisoned image and then triggering (or simply waiting for) a package update. I don't know whether there's an easy way to cause the new device to be the default, but it might be possible--- I'll leave others to judge.

[Colin Watson (cjwatson)]

Unfortunately it's pretty much impossible to tell what's desired. Some people have a "removable" device that's actually plugged in most of the time and which contains OSes they want to boot from, and I think they'd object to GRUB not finding these any more. I can't see how to resolve both at once (even if it were configurable, there'd be debates over the default).

[Dave Martin (dave-martin-arm)]

Indeed... "removable" isn't necessarily a well-defined concept. If I knowingly use a USB HDD for the rootfs, it is "removable"? [discuss]

However, if a _new_, previously unknown bootable target appears, this means:
   * it happened by accident or malice,
   * the administrator did it on purpose and almost certainly Knows What They're Doing, or
   * bus renumbering / device renaming etc. happened (do we need to worry about this possibility?)

Some options might be:

   * during automated upgrades, do not change the set of boot targets: but we can and remove kernels seen in the standard distro locations, and can update the boot configuration for existing targets generally: since the installer or admin already signed off on each target being trusted to boot the system.

   * when manually running update-grub at least print a warning, and possibly require the user to explicitly say "yes" to something before adding a new boot target or something which looks fishy or unintentional

   * ...or even, require the admin to edit the grub config manually for this and don't attempt to automate addition and removal of weird devices. Since only experienced users will be affected anyway, this may be reasonable (bad assumption?)

For this kind of case, I'd tend to expect to have to edit the grub config at least once... but maybe I'm too old-school.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]