All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] implement menu_lock
Date: Sun, 10 Feb 2008 21:59:48 +0100	[thread overview]
Message-ID: <20080210205948.GC4916@thorin> (raw)
In-Reply-To: <200802102113.01523.okuji@enbug.org>

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 /.)



  reply	other threads:[~2008-02-10 21:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-10 13:09 [PATCH] implement menu_lock Robert Millan
2008-02-10 13:11 ` Robert Millan
2008-02-10 20:13 ` Yoshinori K. Okuji
2008-02-10 20:59   ` Robert Millan [this message]
2008-02-10 21:08     ` Robert Millan
2008-02-12  7:41     ` Yoshinori K. Okuji
2009-03-08 13:50       ` phcoder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080210205948.GC4916@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.