From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JOpll-00028x-Si for mharc-grub-devel@gnu.org; Tue, 12 Feb 2008 02:41:33 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JOplk-00027d-EV for grub-devel@gnu.org; Tue, 12 Feb 2008 02:41:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JOplj-00027G-PY for grub-devel@gnu.org; Tue, 12 Feb 2008 02:41:31 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JOplj-00027D-Jc for grub-devel@gnu.org; Tue, 12 Feb 2008 02:41:31 -0500 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JOplj-0004Tm-18 for grub-devel@gnu.org; Tue, 12 Feb 2008 02:41:31 -0500 Received: from ns39764.ovh.net ([91.121.25.85] helo=nexedi.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JOpli-0006AG-1f for grub-devel@gnu.org; Tue, 12 Feb 2008 02:41:30 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id CF60D3D92A for ; Tue, 12 Feb 2008 08:48:48 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Tue, 12 Feb 2008 08:41:24 +0100 User-Agent: KMail/1.9.4 References: <20080210130940.GA3879@thorin> <200802102113.01523.okuji@enbug.org> <20080210205948.GC4916@thorin> In-Reply-To: <20080210205948.GC4916@thorin> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802120841.24890.okuji@enbug.org> X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 3) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) Subject: Re: [PATCH] implement menu_lock X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2008 07:41:32 -0000 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