grub / grub2 conflicts

[Doug Ledford]

On 9/15/2011 10:53 AM, Peter Jones wrote:
> On 09/15/2011 10:36 AM, Richard W.M. Jones wrote:
>> On Thu, Sep 15, 2011 at 03:31:49PM +0100, Matthew Garrett wrote:
>>> On Thu, Sep 15, 2011 at 03:27:16PM +0100, Richard W.M. Jones wrote:
>>>
>>>> So I propose that we drop this conflicts and fix grubby instead.
>>>
>>> No. It is not sane to have multiple bootloaders installed on one
>>> machine.
>>
>> There's an interesting verbal trick there.  "multiple bootloaders" are
>> not installed.  Multiple versions of the grub RPM package are
>> installed.  Only one bootloader would be installed on the host.
> 
> It's really not useful or reasonable to think of grub and grub2 as "multiple
> versions of the same bootloader" - they don't share tools, for example. But
> even so, multiple versions of the same bootloader doesn't make sense either.

For use on a single system I would agree.  It does, however, make just
as much sense as a cross compiler on a different arch host for making
binaries for a breadboard.

>>> Requiring the ability to do so adds a significant amount of
>>> extra complexity to the tools associated with it for no useful benefit.
>>
>> The useful benefit was outlined in the original email.
> 
> It really wasn't - it's still unclear why anybody would choose to do things
> that way. On the face it's a completely wrong choice.

Well, the primary example he gave in another email was resizing of a
guest VM image, which then might mean realigning the image, and if
that's done when the image is up and running and done inside the image,
then you could readjust the boot loader inside the image.  However, as
the tool in question is capable of doing this to an offline image (I
assume by the way Richard talks), it *must* be able to adjust the boot
loader from outside the image or the image won't boot up again.  As a
general use case, assume you are an admin with 100 different images to
manage and you want to resize all of them, having to fire up each image
and resize it from inside the guest and adjust the boot loader from
inside the guest would be a horrible way to do things.  Being able to
use a tool on the host to resize all the images in one go and fix up all
the boot loaders in one go, from the host, not from the guest, is
certainly the way I, as an admin, would want things.

>>> Just install the grub package in the guest, and chroot into the guest if
>>> you need to run grub-install there.
>>
>> Running tools from out of the guest is insecure.  There are several
>> ways in which a guest could exploit the host if we did this.  See
>> "Security" here for some issues:
>>
>> http://libguestfs.org/guestfs.3.html#running_commands
> 
> "I wrote a web page about my opinions" does not make them fact. But even if we
> took as given that it's somehow better not to use packages in the guest, it's
> still not a reason to have the packages *unpacked and installed* on the host
> system. Doing this introduces many more chances for exploitation and plain old
> corruption and errors. At the very least it should be using raw, non-installed
> packages on the host rather than installed ones. Which, by the way, Fedora
> already has tools to accomplish.

See my above comment about cross-compilers.  There are certainly use
cases for having the tool install and live on the host.  As for
security, if you assume that the host is locked down tight with no
running services besides sshd and libvirtd, then it is arguably the
better place to have a tool like grub installed than in the guest which
might be running apache and considerably more open to attack than the host.


-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110916/0b33d791/attachment.bin