grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Boot parameters and geometrical stability


From: phcoder
Subject: Re: [RFC] Boot parameters and geometrical stability
Date: Wed, 03 Sep 2008 20:36:33 +0200
User-agent: Thunderbird 2.0.0.16 (X11/20080724)

Vesa Jääskeläinen wrote:
> That is a valid point.
> 
> Would you prefer to use hardware path to device or what you had in mind
> then? Because this is something that we can left for expert people. Most
> common problem is that user plugs in new drive to system and
> bios/hardware order gets changed or something like that, and that
> renders system unbootable. UUID is perfect solution for that case.
> 
Yes it is, but in my opinion price is too high (shame ubuntu uses this
solution). It's somewhat similar to some solutions found in windows when
  for user convenience they open a big gate for the hackers (e.g. all
users by default are administrators in winxp)
> Possibilites are there, but basically they are limited to something like:
> 
> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
> 
> I do not know if those all would be valid, but I hope you get the idea.

Yes. This is a solution found in grub legacy and I think it's a good one.
> 
> Alternative would be that you integrate some module to core that
> validates your system that there is no extra devices or such.

It's bigger since you require module and has no advantages over using
hardware names. But what we can do is to check if 2 partitions share the
same UUID and if it's the case prompt for password. The problem is that
if the same device is visible twice then it will result in a false
positive. Another solution would be to checksum modules we load. But in
this case after partial update or configuration modification a run
checksum-updater is necessary or at least user will have to enter his
password on the next boot.
> 
> Thanks,
> Vesa Jääskeläinen

Vladimir 'phcoder' Serbinenko




reply via email to

[Prev in Thread] Current Thread [Next in Thread]