grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Allow to add/change menu entry class defaults.
Date: Thu, 24 Dec 2015 11:21:04 +0300	[thread overview]
Message-ID: <CAA91j0XwJoY0KtQAJiu2xpWzDd7r-ud8KpVj4oo-d3VQzHAxBQ@mail.gmail.com> (raw)
In-Reply-To: <567B0A0A.2050804@riseup.net>

On Wed, Dec 23, 2015 at 11:54 PM, Robin Schneider <ypid@riseup.net> 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.


  reply	other threads:[~2015-12-24  8:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22 15:19 [PATCH] Allow to add/change menu entry class defaults Robin Schneider
2015-12-23  6:58 ` Andrei Borzenkov
2015-12-23 20:54   ` Robin Schneider
2015-12-24  8:21     ` Andrei Borzenkov [this message]
2015-12-26 21:17       ` Robin Schneider
2015-12-27 17:03         ` Andrei Borzenkov
2015-12-27 20:44           ` Robin Schneider
2016-01-13 12:12             ` Robin Schneider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA91j0XwJoY0KtQAJiu2xpWzDd7r-ud8KpVj4oo-d3VQzHAxBQ@mail.gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).