Hi, Bean <[EMAIL PROTECTED]> writes:
> First of all, we can store the encrypted password in a variable, like > PASSWORD. It's better to store it in grubenv. as it is more flexible, > and also allows the user to change it from the grub environment. I am not sure if this is what we want. It might be a security risk. > Then, we can add a password hook to normal.mod. Whenever we need > password verification, like before execution of menu or switching to > console mode, we call the hook and check the return value. > > I introduce the attribute list concept in the other post. For example, > we can assign some attribute to a menuitem, one of which is "locked". > If we found this attribute, we call the password hook, otherwise > execute the menu directly. Personally I do not want to limit to passwords only. There might be other ways to authenticate. Perhaps as simple as inserting a card for identification or such. > We can also add a userland command check_password, which check the > password and return true or false. This can be used in script to run > some part of code when password matches. Userland? > Another way for userland interactive is to use variable hook instead > of command. For example, GET_PASSWORD. Whenever its value is query, we > prompt the user for password and return the encrypted value. Here are > some example of its usage: > > # Verify password > if ($PASSWORD = $GET_PASSWORD) then > ... > fi > > # Store the new password > PASSWORD=$GET_PASSWORD > save_env PASSWORD > > This way looks neat, but it requires a working test command to be useful. I think this might become a security risk easily :-/. Although I like exploiting scripting, I prefer to keep security contained to C code. -- Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
