-----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----- _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
