On Sun, Feb 10, 2008 at 09:13:01PM +0100, Yoshinori K. Okuji wrote:
> On Sunday 10 February 2008 14:09, Robert Millan wrote:
> > Implement menu_lock. This is a variable that locks the menu when set.
> >
> > It can be used by users to lock the menu, although there's no way to
> > authenticate users for unlocking it, yet (but the procedure would be
> > independant from this interface).
>
> I think this should be named differently. "menu_lock" sounds like freezing a
> menu, but you also disable entering into the command line.
>
> In GRUB Legacy, I used a variable "auth" to define the state of authorization
> (you can have a look at stage2/stage2.c). Was it so bad?
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.
She can even implement different authorization levels. For example:
set menu_lock=1
menuentry "Unlock the menu" {
echo -n "Password: "
read password
if test $password=grubrocks ; then
unset menu_lock
fi
}
menuentry "Anyone can boot this" {
multiboot /foo
}
menuentry "Only users who unlocked the menu can boot this" {
if ! test $menu_lock=1 ; then
multiboot /bar
fi
}
menuentry "Only a few selected ones can boot this" {
echo -n "Password: "
read password
if test $password=grubisawesome ; then
multiboot /baz
fi
}
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
