[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robin Schneider
Subject: Re: [PATCH] Allow to add/change menu entry class defaults.
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

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 
>> 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]:
> 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
>> - does it address your concern?
> Yes. Looks good.

- -- 
Live long and prosper
Robin `ypid` Schneider


reply via email to

[Prev in Thread] Current Thread [Next in Thread]