On Sunday 10 February 2008 21:59, Robert Millan wrote:
> I didn't see this; it was inspired in the "lock" command in GRUB Legacy.
> But since it only applies to menu, and doesn't lock anything else, I
> thought "menu_lock" would be a good choice.
>
> Since our default state is not to lock the menu, and that would match with
> non-existance of the variable, I think the meaning of the variable should
> be to lock the menu when set. If we make it mean the opposite, e.g.
> auth=1, what do we do when the variable is not set?
>
> You can observe I've been instructed by your advice not to implement ad-hoc
> features, so I tried to avoid some generic "lock" command that would handle
> multiple things depending on the context. With my proposed scheme, we
> provide the primitives and user can do just about anything.
First of all, we need an authorization status at the global level anyway,
because if you can enter into the command line interface, you can bypass
everything.
Once you accept defining an authorization status, you can write this:
menuentry "Anyone can boot this" {
multiboot /foo
}
menuentry "Only users who unlocked the menu can boot this" {
if test $auth != no ; then
multiboot /bar
else
echo You must enter a password before booting this entry.
# Probably better to have a way to exit with an error here!
fi
}
menuentry "Only a few selected ones can boot this" {
echo -n "Password: "
read password
if test $password = grubisawesome ; then
multiboot /baz
else
echo The password you entered was wrong.
# error error
fi
}
But my feeling is that it would be more powerful to implement a password
checker as a command. Scripting allows you to perform many things, if GRUB
provides many commands and control structures, but it looks very tiring to
implement various features (e.g. various encryption schemes, challenge
retries, the translation of prompts, and so on).
Okuji
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
