I agree that with this design grub2 lock are somewhat cumbersome to
implement some schemes. I would prefer a user+C-list design. In this
case a following file be used by group
<username1>:<capability1>,<capability2>,...
<username2>:<capability1>,<capability3>,...
...
E.g.
root:all
wheel:bootnonet
...
This file can also be reversed and list users per capability instead of
capabilities per user
Then an authentication methods would be provided in form of modules each
one using its one configuration to match users to authentication method
(e.g. user-hash or user-fingerprint)
To check the user level a special function would be provided
int grub_user_is_allowed (const char *id)
If user is already authenticated and is allowed to do whatever is
specified by id it returns true, otherwise it proposes the user the list
of available authentication methods and then calls the corresponding
method. A drawback is that user has also to choose the method. Perhaps
we can define methods as being non-blocking? E.g. use checkkey and so
on. The code would be something like:
static char *
auth_user (void)
{
int do_sleep = 100;
for (curauth=authmethods; curauth; curauth=curauth->next)
{
do_sleep = min (do_sleep, curauth->sleep_max);
curauth->init ();
}
while (GRUB_TERM_ASCII_CHAR (grub_getkey ()) != GRUB_TERM_ESC)
{
for (curauth=authmethods; curauth; curauth=curauth->next)
if (username = curauth->check ())
return username;
if (do_sleep)
grub_millisleep (do_sleep)
}
return 0;
}
In this case password module may be waiting for console input and
fingerprint module would scan pci for input from fingerprint scanner
When no clist file is loaded everyone is allowed to do everything
then your menu would look like
clist.txt:
root:cmdline,barboot
user2:bazboot
passwords:
root:grubrocks
user2:grubisawesome
grub.cfg:
clist /clist.txt
passwords /passwords.txt
fingerprints /fingerprints.dat
menuentry "Anyone can boot this" {
multiboot /foo
}
menuentry "Only users who unlocked the menu can boot this" {
if allowed bootbar ; then
multiboot /bar
fi
}
menuentry "Only a few selected ones can boot this" {
if allowed bootbaz; then
multiboot /baz
fi
}
Yoshinori K. Okuji wrote:
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
--
Regards
Vladimir 'phcoder' Serbinenko
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
