From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aJKIK-0003gF-CC for mharc-grub-devel@gnu.org; Wed, 13 Jan 2016 07:12:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJKIG-0003g1-Ve for grub-devel@gnu.org; Wed, 13 Jan 2016 07:12:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJKIC-0007Vl-RN for grub-devel@gnu.org; Wed, 13 Jan 2016 07:12:52 -0500 Received: from mx1.riseup.net ([198.252.153.129]:33154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJKIB-0007VY-NE for grub-devel@gnu.org; Wed, 13 Jan 2016 07:12:48 -0500 Received: from piha.riseup.net (unknown [10.0.1.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 37D531A240D for ; Wed, 13 Jan 2016 12:12:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1452687166; bh=7N4BzdsV5QEx/EUZciutCk+xzlz52NNfWxGb7OIL5/4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=T0XZ3NPOJjxhxu9T8ca4mn5ZMXBiiivAbYfl6xguy3bdoN4UO93S3LL4b53F6Hc7W iVpVHTKLBPLFOigWMoU6R0PskMWPyMQpx9moGqvklLYb4O8pGZtJzLg4K5PAB/DJr5 ju8tdOD4uGnjcT5jYXwVzULsrtPYLJm7DYjJX1xk= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ypid) with ESMTPSA id 886431C033C Subject: Re: [PATCH] Allow to add/change menu entry class defaults. To: grub-devel@gnu.org References: <567969EB.1090109@riseup.net> <567B0A0A.2050804@riseup.net> <567F03CE.9050007@riseup.net> <568019E8.2040301@gmail.com> <56804D9F.20705@riseup.net> From: Robin Schneider Message-ID: <56963F38.6000508@riseup.net> Date: Wed, 13 Jan 2016 13:12:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <56804D9F.20705@riseup.net> Content-Type: text/plain; charset=windows-1252 X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 198.252.153.129 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 12:12:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/27/2015 09:44 PM, Robin Schneider wrote: > On 27.12.2015 18:03, Andrei Borzenkov wrote: >> 27.12.2015 00:17, Robin Schneider ?????: >>> I am sorry for the misunderstanding. I should have explained the=20 >>> indention behind my patch a bit better then just linking to another >>> patch which makes use of the newly introduced variables by this patch= . >>>=20 >>> My indented use case is to allow to add options like '--unrestricted' >>> or '--users "Jane"' to each menuentry generated by grub-mkconfig >>> without altering the scripts itself. >=20 >> Oh, no, sorry. CLASS is for adding --class option and --class option i= s >> for defining icon used to represent menu entry. Please do not misuse i= t >> for something else. >=20 > Sorry for that. >=20 >> I try to understand possible use cases. >=20 >> Please get a look at=20 >> https://lists.gnu.org/archive/html/grub-devel/2015-05/msg00170.html >> thread. SUSE has actually implemented my suggestion. This gives us "al= l >> menu entries unrestricted" case. >=20 > The patch suggested would not allow to overwrite icons via the --class > option. Otherwise it looks very similar to mine :) >=20 >=20 >> Do you really have situation where you need separate category of users >> that won't have access to CLI but will be the *only* users allowed to >> select non-default menu entry? Moreover, do you really need to allow >> different users to boot different categories of menu entries? >=20 > I personally don=92t need either right now. The "all menu entries > unrestricted" thing is enough for me. But allowing to specify a user > instead of --unrestricted to all menu entries should not make this patc= h > more complected so I still would like to allow it. I attached an update= d > patch :) >=20 > Although I don=92t need either of those features, I still think that th= ey can > be useful. For example, you want to use --unrestricted for the default > boot entry, but boot images like memtest+ (as packaged by Debian [1]) o= nly > for authenticated user(s). Another example would be when users put DBAN > into the boot menu :) (Sure, memtest+ and DBAN are not included in upst= ream > grub.d, but it should emphasize the point that it can make sense to > restrict based on type of bootable image/system). >=20 > Another reason for restricting based on type might be if you have insta= lled > a distribution/OS (which is not the default entry), lets say windows, w= hich > the administrator thinks could be used to manipulate the GRUB or other=20 > configuration on the system when booted thus restricting it with a > separate user (--users). >=20 > [1]: https://packages.debian.org/jessie/memtest86+ >=20 > You can chose if you want to apply my updated/simplified patch, my > previous patch allowing restricts based on type or the patch from Micha= el > Chang (or none of the above :) ). Any updates? >=20 >>> BTW: The efi menuentry has the class 'windows'. Is that correct? My=20 >>> patch assumes that this menuentry is indented for UEFI applications. >>>=20 >=20 >> Well, so far upstream os-prober only detects Windows on EFI. But yes, >> SUSE includes additional script. >=20 >> See https://lists.gnu.org/archive/html/grub-devel/2015-12/msg00103.htm= l >> - does it address your concern? >=20 > Yes. Looks good. - --=20 Live long and prosper Robin `ypid` Schneider -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWlj84AAoJEIb9mAu/GkD4FTsQAIdpf5d7Sd1c2aP+ONmeeS99 5/uWy0xAAGE6Uck1ht2BN+NneX5o7AEAFC1ttGe7bOXJho7vz8A3/RQ2XN5tjjj1 JXzuo5s85C9b5B/AMIW4y/H276Px5sMVNKv42tKuVQBGXU7vheyfQt27LpvpuzEq jqJrgPLbgGQBgyiImUTkWiQkF6fzxNlhXu96eymrqLlzR/XcEEox5cKqCgvjcm/V KfpUzyHtnkBSsFcjXLA+JjFc+IB53oMJouThhggUXPB4M/UQ8vJu7TC8ai2Cbvpg TRNIDTZ7GdSG/LcHYndNrcGhrhEnlbFTmoR86PJ7XtcfLhs4b8/mvbZlT178qK/i tBB0i8y+yD6YWeeB/A9sfzpcZPo9L90Ug5ipZuMQHwcLsJo+MHVCHGRHsrskSova 6nve+iBYNLy0dEwxBTHpu5PK6hsjfS1kGzupzR9hSa1lbYFvQc+Gy4b8L7DS9AjC Cjb42b73BwI6gibMaq7W7wMk0v1R9ycOxO1/0qZ6+SiVfGtv/xG85qf6vOClxX4f kVCT+5kyunWuShCvFMgcI2jgajlg+ak1iyjm0bo4PGEd5kdMckXJddp4MKwc0SIH cvPTVQ1e429TT8w6KteDI58WiJJKb38l8nTomHku2bDV2Vspu2qdNo7UT47+yyGw tsF29ubKGH6uDSJbzog5 =3DyyKo -----END PGP SIGNATURE-----