Syslinux - Apr 2014 - Issues with syslinux_run_command(str) and parameters

I did confirm earlier that this does work, and combined with a MENU HIDDEN to
hide it from the visible menu it is a possible solution. I originally assumed
that this was due to that going down a different code path and did not mention
it, apologies. The scale of my menu makes doubling/tripling menu entries less
ideal, though.

Do we consider it intended functionality that modules such as whichsys will not
work under ALLOWOPTIONS 0? A strict reading of the wiki would allow for this, as
the subsequently loaded module does not have parameters in an append label:
http://www.syslinux.org/wiki/index.php/SYSLINUX#ALLOWOPTIONS_flag_val

Naturally given my situation here, I think it would be ideal if we could
separate disabling user edits & commands from blocking modules loading other
modules, etc. :)
--Ian
> From: ady-sf at hotmail.com
> To: syslinux at zytor.com
> Date: Wed, 30 Apr 2014 03:36:35 +0300
> Subject: Re: [syslinux] Issues with syslinux_run_command(str) and
parameters
> 
> Try the following and let us know. If it doesn't work, we'll try 
> other alternatives.
> 
>  ***
>  
>  DEFAULT vesamenu.c32
>  ALLOWOPTIONS 0
>  
>  LABEL test
>  COM32 whichsys.c32
>  APPEND -iso- iso -sys- sys
>  
>  LABEL iso
>  LINUX memdisk
>  APPEND initrd=fdboot.img
>  
>  LABEL sys
>  LINUX memdisk
>  APPEND initrd=fdboot.img
>  
>  ***
> 
> Regards,
> Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux

> 
> I did confirm earlier that this does work, and combined with a MENU 
> HIDDEN to hide it from the visible menu it is a possible solution. I 
> originally assumed that this was due to that going down a different 
> code path and did not mention it, apologies.?The scale of my menu 
> makes doubling/tripling menu entries less ideal, though.? 
> 
> 
> Do we consider it intended functionality that modules such as 
> whichsys will not work under ALLOWOPTIONS 0? A strict reading of the 
> wiki would allow for this, as the subsequently loaded module does not 
> have parameters in an append 
> label:?http://www.syslinux.org/wiki/index.php/SYSLINUX#ALLOWOPTIONS_fl
> ag_val
> 
> 
> Naturally given my situation here, I think it would be ideal if we 
> could separate disabling user edits & commands from blocking modules 
> loading other modules, etc. :)
> 
> --Ian
 
Just FYI... You could potentially avoid MENU HIDDEN. A different 
directive, MENU HIDE, might be convenient. It all depends on the 
whole set of cfg files, and on your goals. For example:
 LABEL sys
 MENU HIDE
 LINUX memdisk
 INITRD myimage
 APPEND floppy raw


Regarding "ALLOWOPTIONS 0"...

It is not blocking modules. And this directive can also be used in 
CLI too, without a menu.

In particular, these tests show you that it is not blocking 
whichsys.c32.

You might want to read the meaning of this directive as: "only allow 
LABELs (as-is) to be executed", but that would be slightly 
inaccurate, as any (type of) command can be executed, as long as it 
doesn't need additional arguments.

So, if we use "ALLOWOPTIONS 0", the following command (from CLI) is 
not allowed:
 cat.c32 help.txt

just because "cat.c32" needs an additional argument, a file 
("help.txt").

In case we had an entry in the cfg file such as:
 LABEL cat_help
 COM32 cat.c32
 APPEND help.txt

then we could execute the command:
 cat_help

which doesn't need additional arguments.

We could also execute "ls.c32", because it doesn't need additional
arguments.

In your example, 'memdisk' requires additional arguments (at least 
the "initrd"). So, if you define a LABEL entry for the exact command, 
you should be able to execute it (by means of the corresponding 
"label").

Regards,
Ady.

Yes, MENU HIDE would work as well, but still requires additional entries for
each case (possible entries for pxe, syslinux, isolinux, cpu architectures, PCI
devices, lua scripting scenarios, etc.)

By blocking modules, I meant that as long as I disable user editing of menu
commands via ALLOWOPTIONS 0, I cannot use any of the following com32 modules
without creating duplicate LABEL entries for each possible scenario. All of
these modules use syslinux_run_cmd() so parameters on the command line will not
be received:
- gfxboot.c32- cmd.c32- lua.c32- ethersel.c32- ifcpu.c32- ifcpu64.c32-
ifmemdsk.c32- ifplop.c32- whichsys.c32- rosh.c32


This doesn't feel like an intended restriction of ALLOWOPTIONS 0.

--Ian
> From: ady-sf at hotmail.com
> To: syslinux at zytor.com
> Date: Wed, 30 Apr 2014 05:06:55 +0300
> Subject: Re: [syslinux] Issues with syslinux_run_command(str) and
parameters
> 
> 
> > 
> > I did confirm earlier that this does work, and combined with a MENU 
> > HIDDEN to hide it from the visible menu it is a possible solution. I 
> > originally assumed that this was due to that going down a different 
> > code path and did not mention it, apologies. The scale of my menu 
> > makes doubling/tripling menu entries less ideal, though.  
> > 
> > 
> > Do we consider it intended functionality that modules such as 
> > whichsys will not work under ALLOWOPTIONS 0? A strict reading of the 
> > wiki would allow for this, as the subsequently loaded module does not 
> > have parameters in an append 
> > label: http://www.syslinux.org/wiki/index.php/SYSLINUX#ALLOWOPTIONS_fl
> > ag_val
> > 
> > 
> > Naturally given my situation here, I think it would be ideal if we 
> > could separate disabling user edits & commands from blocking
modules
> > loading other modules, etc. :)
> > 
> > --Ian
>  
> Just FYI... You could potentially avoid MENU HIDDEN. A different 
> directive, MENU HIDE, might be convenient. It all depends on the 
> whole set of cfg files, and on your goals. For example:
>  LABEL sys
>  MENU HIDE
>  LINUX memdisk
>  INITRD myimage
>  APPEND floppy raw
> 
> 
> Regarding "ALLOWOPTIONS 0"...
> 
> It is not blocking modules. And this directive can also be used in 
> CLI too, without a menu.
> 
> In particular, these tests show you that it is not blocking 
> whichsys.c32.
> 
> You might want to read the meaning of this directive as: "only allow 
> LABELs (as-is) to be executed", but that would be slightly 
> inaccurate, as any (type of) command can be executed, as long as it 
> doesn't need additional arguments.
> 
> So, if we use "ALLOWOPTIONS 0", the following command (from CLI)
is
> not allowed:
>  cat.c32 help.txt
> 
> just because "cat.c32" needs an additional argument, a file 
> ("help.txt").
> 
> In case we had an entry in the cfg file such as:
>  LABEL cat_help
>  COM32 cat.c32
>  APPEND help.txt
> 
> then we could execute the command:
>  cat_help
> 
> which doesn't need additional arguments.
> 
> We could also execute "ls.c32", because it doesn't need
additional
> arguments.
> 
> In your example, 'memdisk' requires additional arguments (at least 
> the "initrd"). So, if you define a LABEL entry for the exact
command,
> you should be able to execute it (by means of the corresponding 
> "label").
> 
> Regards,
> Ady.
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux