Idea: use menu hook to implement the savedefault command

Idea: use menu hook to implement the savedefault command

[Bean]

Hi,

Now it's possible to implement savedefault with load_env and save_env,
but the problem is we need to add it to every menuitem, it's tedious
process, and new item don't get it automatically.

I'm thinking about using menu hook to solve this. I can think of two
implementation:

1. Function interface

We can install hooks, which get called just before the menu is invoked.

2. Script interface

We can use certain variable to specific the command to use, for example:

set MENU_PRELOAD=save_env default

The first menu is easier to implement, but the second one is more flexible.

btw, we can also use this to implement the password command. Just
before the menu is executed, we call the hook. If the password is not
match, we return false and it quit. But it's a little tricky this
time, as some item may not be protected. For this, we introduce
another concept, the attributes of an menu item. For example, we can
set an lock attribute that indicate that this item should be verified
for password. The attribute list is passed to the hook function, so
they can just lookup it's value and decide what to do.

Note that the attribute concept is already used in Colin's GSOC
project, it uses to specific the icon of a boot item, we just extent
it to include other attributes.

-- 
Bean

-- 
Bean

Re: Idea: use menu hook to implement the savedefault command

[Robert Millan]

On Tue, Aug 12, 2008 at 05:03:10AM +0800, Bean wrote:
> Hi,
> 
> Now it's possible to implement savedefault with load_env and save_env,
> but the problem is we need to add it to every menuitem, it's tedious
> process, and new item don't get it automatically.

After discussing this on IRC, I just thought of another alternative.  We
could add a pair of functions to update-grub_lib, like:

begin_menuentry ()
{
  title=$1
  echo "menuentry \"$title\" {"
  echo "do some env-edit magic"
}

end_menuentry ()
{
  echo "}"
}

then have each of the /etc/grub.d modules that add menuentries use these
functions instead of creating the menuentry directly.

As a side-effect benefit, the /etc/grub.d modules become a bit more
readable.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Idea: use menu hook to implement the savedefault command

[Bean]

On Tue, Aug 12, 2008 at 5:32 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, Aug 12, 2008 at 05:03:10AM +0800, Bean wrote:
>> Hi,
>>
>> Now it's possible to implement savedefault with load_env and save_env,
>> but the problem is we need to add it to every menuitem, it's tedious
>> process, and new item don't get it automatically.
>
> After discussing this on IRC, I just thought of another alternative.  We
> could add a pair of functions to update-grub_lib, like:
>
> begin_menuentry ()
> {
>  title=$1
>  echo "menuentry \"$title\" {"
>  echo "do some env-edit magic"
> }
>
> end_menuentry ()
> {
>  echo "}"
> }
>
> then have each of the /etc/grub.d modules that add menuentries use these
> functions instead of creating the menuentry directly.
>
> As a side-effect benefit, the /etc/grub.d modules become a bit more
> readable.

Hi,

Oh right, if you can do it in update-grub, it's probably better to do
it there. The above post also contain some idea about the
implementation of password command, perhaps I post a seperate post for
it.

-- 
Bean

Re: Idea: use menu hook to implement the savedefault command

[Robert Millan]

On Tue, Aug 12, 2008 at 09:27:42AM +0800, Bean wrote:
> On Tue, Aug 12, 2008 at 5:32 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > On Tue, Aug 12, 2008 at 05:03:10AM +0800, Bean wrote:
> >> Hi,
> >>
> >> Now it's possible to implement savedefault with load_env and save_env,
> >> but the problem is we need to add it to every menuitem, it's tedious
> >> process, and new item don't get it automatically.
> >
> > After discussing this on IRC, I just thought of another alternative.  We
> > could add a pair of functions to update-grub_lib, like:
> >
> > begin_menuentry ()
> > {
> >  title=$1
> >  echo "menuentry \"$title\" {"
> >  echo "do some env-edit magic"
> > }
> >
> > end_menuentry ()
> > {
> >  echo "}"
> > }
> >
> > then have each of the /etc/grub.d modules that add menuentries use these
> > functions instead of creating the menuentry directly.
> >
> > As a side-effect benefit, the /etc/grub.d modules become a bit more
> > readable.
> 
> Hi,
> 
> Oh right, if you can do it in update-grub, it's probably better to do
> it there.

Ok, I'll see about that.

> The above post also contain some idea about the
> implementation of password command, perhaps I post a seperate post for
> it.

Notice there's already an implementation of a lock command:

  http://www.mail-archive.com/grub-devel@gnu.org/msg05350.html

which, I think, even without password it would satisfy most of the users who
want lock/password.  I recommend you read that thread before venturing into
implement it (Okuji didn't like my initial proposal, and I run out of time
to find/implement another approach).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Idea: use menu hook to implement the savedefault command

[Bean]

On Tue, Aug 12, 2008 at 4:52 PM, Robert Millan <rmh@aybabtu.com> wrote:
> Notice there's already an implementation of a lock command:
>
>  http://www.mail-archive.com/grub-devel@gnu.org/msg05350.html
>
> which, I think, even without password it would satisfy most of the users who
> want lock/password.  I recommend you read that thread before venturing into
> implement it (Okuji didn't like my initial proposal, and I run out of time
> to find/implement another approach).

Hi,

I notice an issue with that implementation. For example, if
menu_lock=1, how do you unlock it ? Remember that "Unlock the menu" is
an menu item as well, so you can't get to it in the first place,
unless you also specify text of menu somewhere, or use another
variable, for example:

set menu_lock=1
set menu_unlock_menu=Unlock the menu

Besides, we might need to fine tune auth with scripting, like
protecting only some of the commands.

-- 
Bean

Re: Idea: use menu hook to implement the savedefault command

[Robert Millan]

On Tue, Aug 12, 2008 at 05:38:16PM +0800, Bean wrote:
> On Tue, Aug 12, 2008 at 4:52 PM, Robert Millan <rmh@aybabtu.com> wrote:
> > Notice there's already an implementation of a lock command:
> >
> >  http://www.mail-archive.com/grub-devel@gnu.org/msg05350.html
> >
> > which, I think, even without password it would satisfy most of the users who
> > want lock/password.  I recommend you read that thread before venturing into
> > implement it (Okuji didn't like my initial proposal, and I run out of time
> > to find/implement another approach).
> 
> Hi,
> 
> I notice an issue with that implementation. For example, if
> menu_lock=1, how do you unlock it ? Remember that "Unlock the menu" is
> an menu item as well, so you can't get to it in the first place,
> unless you also specify text of menu somewhere, or use another
> variable, for example:
> 
> set menu_lock=1
> set menu_unlock_menu=Unlock the menu
> 
> Besides, we might need to fine tune auth with scripting, like
> protecting only some of the commands.

My idea was to implement unlock in scripting.  So you could do something like:

menuentry unlock {
	echo Password:
	read user_pass
	if [ $user_pass = foo ] ; then
		unset menu_lock
	fi
}

but Okuji had some objections to this (see the thread I pasted)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Idea: use menu hook to implement the savedefault command

[Bean]

On Tue, Aug 12, 2008 at 6:15 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, Aug 12, 2008 at 05:38:16PM +0800, Bean wrote:
>> On Tue, Aug 12, 2008 at 4:52 PM, Robert Millan <rmh@aybabtu.com> wrote:
>> > Notice there's already an implementation of a lock command:
>> >
>> >  http://www.mail-archive.com/grub-devel@gnu.org/msg05350.html
>> >
>> > which, I think, even without password it would satisfy most of the users who
>> > want lock/password.  I recommend you read that thread before venturing into
>> > implement it (Okuji didn't like my initial proposal, and I run out of time
>> > to find/implement another approach).
>>
>> Hi,
>>
>> I notice an issue with that implementation. For example, if
>> menu_lock=1, how do you unlock it ? Remember that "Unlock the menu" is
>> an menu item as well, so you can't get to it in the first place,
>> unless you also specify text of menu somewhere, or use another
>> variable, for example:
>>
>> set menu_lock=1
>> set menu_unlock_menu=Unlock the menu
>>
>> Besides, we might need to fine tune auth with scripting, like
>> protecting only some of the commands.
>
> My idea was to implement unlock in scripting.  So you could do something like:
>
> menuentry unlock {
>        echo Password:
>        read user_pass
>        if [ $user_pass = foo ] ; then
>                unset menu_lock
>        fi
> }
>
> but Okuji had some objections to this (see the thread I pasted)

Hi,

I know that, but isn't "unlock" another menu item which would normally
be locked by menu_lock ? You can hard coded it to ignore the "unlock"
menu, but what if user want to use another name.

-- 
Bean

Re: Idea: use menu hook to implement the savedefault command

[Robert Millan]

On Tue, Aug 12, 2008 at 06:38:08PM +0800, Bean wrote:
> >
> > My idea was to implement unlock in scripting.  So you could do something like:
> >
> > menuentry unlock {
> >        echo Password:
> >        read user_pass
> >        if [ $user_pass = foo ] ; then
> >                unset menu_lock
> >        fi
> > }
> >
> > but Okuji had some objections to this (see the thread I pasted)
> 
> Hi,
> 
> I know that, but isn't "unlock" another menu item which would normally
> be locked by menu_lock ? You can hard coded it to ignore the "unlock"
> menu, but what if user want to use another name.

My patch only implements "locking" in the sense that you can't get access to
command-line, or edit menuentries, but you can run all existing entries.

If you want to "lock" in the sense of locking a single entry, my intention
was that this could be done with scripting as well:

menuentry locked {
	if [ $menu_lock = 1 ] ; then
		echo fail
	else
		blah
	fi
}

Is that what you mean?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Idea: use menu hook to implement the savedefault command

[Bean]

On Tue, Aug 12, 2008 at 6:44 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Tue, Aug 12, 2008 at 06:38:08PM +0800, Bean wrote:
>> >
>> > My idea was to implement unlock in scripting.  So you could do something like:
>> >
>> > menuentry unlock {
>> >        echo Password:
>> >        read user_pass
>> >        if [ $user_pass = foo ] ; then
>> >                unset menu_lock
>> >        fi
>> > }
>> >
>> > but Okuji had some objections to this (see the thread I pasted)
>>
>> Hi,
>>
>> I know that, but isn't "unlock" another menu item which would normally
>> be locked by menu_lock ? You can hard coded it to ignore the "unlock"
>> menu, but what if user want to use another name.
>
> My patch only implements "locking" in the sense that you can't get access to
> command-line, or edit menuentries, but you can run all existing entries.
>
> If you want to "lock" in the sense of locking a single entry, my intention
> was that this could be done with scripting as well:
>
> menuentry locked {
>        if [ $menu_lock = 1 ] ; then
>                echo fail
>        else
>                blah
>        fi
> }
>
> Is that what you mean?

Hi,

Oh, I see. I thought you lock the menu as well.

-- 
Bean

Re: Idea: use menu hook to implement the savedefault command

[Marco Gerards]

Bean <bean123ch@gmail.com> writes:

> Hi,
>
> Now it's possible to implement savedefault with load_env and save_env,
> but the problem is we need to add it to every menuitem, it's tedious
> process, and new item don't get it automatically.
>
> I'm thinking about using menu hook to solve this. I can think of two
> implementation:
>
> 1. Function interface
>
> We can install hooks, which get called just before the menu is invoked.
>
> 2. Script interface
>
> We can use certain variable to specific the command to use, for example:
>
> set MENU_PRELOAD=save_env default

Wouldn't this be a BOOT_PRELOAD?

I thought about this before (see archives about scripting), making it
possible for the user to add hooks.

In C:

... menu code ...
/* The `menu' hook has one argument.  */
grub_hook_invoke ("menu", 1, arglist);


In scripting:

function menu_hook_handler()
  save_env;

hook --register --hook=menu --script menu_hook_handler

Or do you think I am crazy now? ;-)

This will involve some scripting hacking, but might pay off.  Do you
think this is too complex for users?

Re: Idea: use menu hook to implement the savedefault command

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

El mié, 13-08-2008 a las 12:31 +0200, Marco Gerards escribió:
> Bean <bean123ch@gmail.com> writes:
> 
> > Hi,
> >
> > Now it's possible to implement savedefault with load_env and save_env,
> > but the problem is we need to add it to every menuitem, it's tedious
> > process, and new item don't get it automatically.
> >
> > I'm thinking about using menu hook to solve this. I can think of two
> > implementation:
> >
> > 1. Function interface
> >
> > We can install hooks, which get called just before the menu is invoked.
> >
> > 2. Script interface
> >
> > We can use certain variable to specific the command to use, for example:
> >
> > set MENU_PRELOAD=save_env default
> 
> Wouldn't this be a BOOT_PRELOAD?
> 
> I thought about this before (see archives about scripting), making it
> possible for the user to add hooks.
> 
> In C:
> 
> ... menu code ...
> /* The `menu' hook has one argument.  */
> grub_hook_invoke ("menu", 1, arglist);
> 
> 
> In scripting:
> 
> function menu_hook_handler()
>   save_env;
> 
> hook --register --hook=menu --script menu_hook_handler
> 
> Or do you think I am crazy now? ;-)
> 
> This will involve some scripting hacking, but might pay off.  Do you
> think this is too complex for users?
It might be unnecessarily complex, yes. What about a C#-delegate-like
approach? e.g.:

function myhook() {
  save_env
}

BOOT_PRELOAD += myhook

> 
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: Idea: use menu hook to implement the savedefault command

[Robert Millan]

On Wed, Aug 13, 2008 at 01:36:44PM +0200, Javier Martín wrote:
> It might be unnecessarily complex, yes. What about a C#-delegate-like
> approach? e.g.:
> 
> function myhook() {
>   save_env
> }

While in the process of designing interfaces, finding inspiration in patent
encumbered technologies is one of the last things I would recommend.

Sometimes the GNU project has gone to great lengths to avoid being covered
by patents, like in the development of gzip, or in its endorsement of the
Xiph Foundation.  I don't personally think we need to be so radical for GRUB,
but we could at least be careful.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Idea: use menu hook to implement the savedefault command

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

El mié, 13-08-2008 a las 13:48 +0200, Robert Millan escribió:
> On Wed, Aug 13, 2008 at 01:36:44PM +0200, Javier Martín wrote:
> > It might be unnecessarily complex, yes. What about a C#-delegate-like
> > approach? e.g.:
> > 
> > function myhook() {
> >   save_env
> > }
> 
> While in the process of designing interfaces, finding inspiration in patent
> encumbered technologies is one of the last things I would recommend.
While parts of the .NET class library most certainly contain patented
code, the C# language itself is part of an ECMA specification, and thus
the delegate _syntax_ (not the actual implementation) would be safe to
use... Or so I think - patents make my mind spin T_T
> 
> Sometimes the GNU project has gone to great lengths to avoid being covered
> by patents, like in the development of gzip, or in its endorsement of the
> Xiph Foundation.  I don't personally think we need to be so radical for GRUB,
> but we could at least be careful.
> 

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: Idea: use menu hook to implement the savedefault command

[Robert Millan]

On Wed, Aug 13, 2008 at 02:11:54PM +0200, Javier Martín wrote:
> El mié, 13-08-2008 a las 13:48 +0200, Robert Millan escribió:
> > On Wed, Aug 13, 2008 at 01:36:44PM +0200, Javier Martín wrote:
> > > It might be unnecessarily complex, yes. What about a C#-delegate-like
> > > approach? e.g.:
> > > 
> > > function myhook() {
> > >   save_env
> > > }
> > 
> > While in the process of designing interfaces, finding inspiration in patent
> > encumbered technologies is one of the last things I would recommend.
> While parts of the .NET class library most certainly contain patented
> code, the C# language itself is part of an ECMA specification, and thus
> the delegate _syntax_ (not the actual implementation) would be safe to
> use... Or so I think - patents make my mind spin T_T

Being part of ECMA isn't any garantee of not being patent encumbered.  ECMA
will happily bless any specification you give them, even if it contains
technical flaws, provided it's accompanied by enough money (OOXML is a good
example of this).

Last I checked, Microsoft had different patent policies for parts inside
the spec than for parts outside of it, but they're both written in complex
wording with lots of requisites that makes it very difficult to be sure the
code will be free for every user.

Since there isn't any real benefit for us in using their technology as a
reference, I believe it's much better to avoid the problem altogether by
not doing so.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Idea: use menu hook to implement the savedefault command

[Bean]

Hi,

Now it's possible to implement savedefault with load_env and save_env,
but the problem is we need to add it to every menuitem, it's tedious
process, and new item don't get it automatically.

I'm thinking about using menu hook to solve this. I can think of two
implementation:

1. Function interface

We can install hooks, which get called just before the menu is invoked.

2. Script interface

We can use certain variable to specific the command to use, for example:

set MENU_PRELOAD=save_env default

The first menu is easier to implement, but the second one is more flexible.

btw, we can also use this to implement the password command. Just
before the menu is executed, we call the hook. If the password is not
match, we return false and it quit. But it's a little tricky this
time, as some item may not be protected. For this, we introduce
another concept, the attributes of an menu item. For example, we can
set an lock attribute that indicate that this item should be verified
for password. The attribute list is passed to the hook function, so
they can just lookup it's value and decide what to do.

Note that the attribute concept is already used in Colin's GSOC
project, it uses to specific the icon of a boot item, we just extent
it to include other attributes.

-- 
Bean