Re: [PATCH] implement menu_lock

["Yoshinori K. Okuji" <okuji@enbug.org>]

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