Re: [PATCH] Allow to add/change menu entry class defaults.

[Robin Schneider <ypid@riseup.net>]

-----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 
>>> indention behind my patch a bit better then just linking to another
>>> patch which makes use of the newly introduced variables by this patch.
>>> 
>>> 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.
> 
>> Oh, no, sorry. CLASS is for adding --class option and --class option is
>> for defining icon used to represent menu entry. Please do not misuse it
>> for something else.
> 
> Sorry for that.
> 
>> I try to understand possible use cases.
> 
>> Please get a look at 
>> https://lists.gnu.org/archive/html/grub-devel/2015-05/msg00170.html
>> thread. SUSE has actually implemented my suggestion. This gives us "all
>> menu entries unrestricted" case.
> 
> The patch suggested would not allow to overwrite icons via the --class
> option. Otherwise it looks very similar to mine :)
> 
> 
>> 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?
> 
> I personally don’t 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 patch
> more complected so I still would like to allow it. I attached an updated
> patch :)
> 
> Although I don’t need either of those features, I still think that they 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]) only
> for authenticated user(s). Another example would be when users put DBAN
> into the boot menu :) (Sure, memtest+ and DBAN are not included in upstream
> grub.d, but it should emphasize the point that it can make sense to
> restrict based on type of bootable image/system).
> 
> Another reason for restricting based on type might be if you have installed
> a distribution/OS (which is not the default entry), lets say windows, which
> the administrator thinks could be used to manipulate the GRUB or other 
> configuration on the system when booted thus restricting it with a
> separate user (--users).
> 
> [1]: https://packages.debian.org/jessie/memtest86+
> 
> You can chose if you want to apply my updated/simplified patch, my
> previous patch allowing restricts based on type or the patch from Michael
> Chang (or none of the above :) ).

Any updates?

> 
>>> BTW: The efi menuentry has the class 'windows'. Is that correct? My 
>>> patch assumes that this menuentry is indented for UEFI applications.
>>> 
> 
>> Well, so far upstream os-prober only detects Windows on EFI. But yes,
>> SUSE includes additional script.
> 
>> See https://lists.gnu.org/archive/html/grub-devel/2015-12/msg00103.html
>> - does it address your concern?
> 
> Yes. Looks good.

- -- 
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
=yyKo
-----END PGP SIGNATURE-----