grub-devel
[Top][All Lists]
Advanced

[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: Sat, 26 Dec 2015 22:17:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 24.12.2015 09:21, Andrei Borzenkov wrote:
> On Wed, Dec 23, 2015 at 11:54 PM, Robin Schneider <address@hidden> wrote:
>> Thanks for the input. I agree that my first patch was probably a bit to
>> flexible. I attached a updated patch.
>>
> 
> I'm still unsure what problem it tries to solve and whether it solves
> problem it intends to solve.
> 
> So you say
> 
>> Useful for changing the default access level for menu entries when using
>> GRUBs password protection feature.
> 
> a) This does not change any "access level" whatever it means. It only
> changes what icon is displayed for menu entry.

> b) it is all or nothing. The first found icon is used so either all
> menu entries are displayed with "need authentication" or none.
> 
> c) if it is all or nothing then the same can trivially be implemented
> by replacing one set of icons ("unlocked") with another set of icons
> ("locked") during bootloader reconfiguration. This should be done by
> tool you use to configure bootloader, grub-mkconfig has no knowledge
> about access restrictions anyway.
> 
> So either it is trivially implemented without any need to change
> grub-mkconfig or it does not solve the problem anyway.
> 
> But idea itself is actually interesting. Icon manager in grub could
> select different icon if menu entry requires authentication. Or it
> could display overlay (which is probably better). And it actually can
> dynamically decide whether to display this overlay depending on
> whether user is already authenticated.
> 
> How does it sound?
> 
> P.S. current situation with grub-mkconfig I do not like at all. It
> became de-facto standard tool to configure GRUB by distributions but
> it does not provide any sane way to differentiate between distribution
> default vs. local admin configuration. And variables you propose sound
> exactly like the type that will hit this confusion. We need to solve
> this before.

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. Although the scripts end up under /etc in Debian, I did not
think that changing these files (and `dpkg-divert`ing them) would be such a good
idea. I have been searching for how to configure password protection and I did
only find "hacks" which either suggest to edit the grub config under /boot/grub
(which is totally outdated because the configurations is automatically generated
in Debian) or change the "CLASS" variable in the grub.d scripts [12]0_.*
scripts. So I did go with the later option. Patching these scripts with
configuration management was not ideal so I decided to propose this patch
upstream. With this patch in place it will be possible to configure this in
/etc/default/grub without touching the scripts.

This patch addresses the issue which is mentioned in this article (At least when
the assumption is true that all menuentry of the same distribution should get
the same restrictions/options):
https://help.ubuntu.com/community/Grub2/Passwords#Protecting_Menuentries
"There is currently no automated method of adding users or designating menu
items to be protected. The user must manually edit the GRUB 2 scripts."

Thanks for the second review. You are right, adding this to the CLASS variable
(and also the naming) was not ideal. I attached an updated patch which should
address these issues. This patch should also allow to overwrite icon files
because the variable is placed before the CLASS variable.

BTW: The efi menuentry has the class 'windows'. Is that correct? My patch
assumes that this menuentry is indented for UEFI applications.

- -- 
Live long and prosper
Robin `ypid` Schneider
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWfwPOAAoJEIb9mAu/GkD4XOMP/3iEyvNc4WrVk8y6ek+/e9DB
Zk4F3PmVE2lhbnvCcw0cxDH5XfjXwSw9qa6qKYodQtw89I/QcmMmpDuObqTZfdgn
fO4zYcBpm7uBNjH7YLakRtlXvxi1pMifSk9XyR7W4vnHx6b1NyxXkb5gjx4ux88X
xWyIe6zhdF/Ns+Pb9rxYr4ezsHfpZjLv9ZwmBvjwLfg8I3/jPB/r3WPg8rZPpNyN
HeHBIHTE/NeqEgkt3iEofuXQxPYOtA/FamUecwsIHciei33Q6meEsTULuiu1Oa+I
siTP7XnODrOkyvN9+RSdWQBUfk+PmXzf4L/qmVJzALqnk1U888gJjT+vxzINkBAR
RNAS1RLRTZAVe1rJlEGy6XlIdCLCU9ujm0HxT0xdpwceSVaK0DSRMK+QHPMNDspn
Xxjex9NIUgSvjVubNSDiW5hmmP5sJuUfRC5EG6++O0pU2X8sAimHxWRa5HhZqfjo
kuF4dGn918foGMNdN3RzNGcH3SUEsQyvQfZEFctJ63sFqHa+nsicaDxYcvqKl9VT
4Tm7PlbgWTDwUpIu1y8NOjyupcjSZtCrBGXwJbo/NMhwPQFHG/f26wP28ofrc2hD
hl8b7SC+aCd+CA9DFVOUL2ahXUexs8aSeefGC9gR8kQnskDX5AYXUtC7oN5PwBIC
s/RWiPzPnc1QR4L0nzuZ
=HTuO
-----END PGP SIGNATURE-----

Attachment: 0001-Added-GRUB_-_MENUENTRY_OPTIONS-variables-to-configur.patch
Description: Text Data

Attachment: 0001-Added-GRUB_-_MENUENTRY_OPTIONS-variables-to-configur.patch.sig
Description: PGP signature


reply via email to

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