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

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

I didn't see any further communication here; would anyone be against my
submitting/proposing a patch for this?

I can see two possible approaches. One approach would be to isolate the
restriction on user commands away from syslinux_run_command / load_kernel.

Another would perhaps be to add support for a 'NOTAB' or
'NOTABTOEDIT' option. There already exists a NOESCAPE setting, so the
remaining piece would be restricting tab. (And perhaps holding shift to get to
the console.. Hmm.)

I would appreciate any suggestions :)

Thank you,--Ian
> From: ian at internals.io
> To: ady-sf at hotmail.com; syslinux at zytor.com
> Date: Tue, 29 Apr 2014 21:27:46 -0500
> Subject: Re: [syslinux] Issues with syslinux_run_command(str) and
parameters
> 
> 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
>  		 	   		  
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux

> I didn't see any further communication here; would anyone be
> against my submitting/proposing a patch for this? 
Contributions are always welcome.
> 
> I can see two possible approaches. One approach would be to
> isolate the restriction on user commands away from
> syslinux_run_command / load_kernel. 
> 
> Another would perhaps be to add support for a 'NOTAB' or
> 'NOTABTOEDIT' option. There already exists a NOESCAPE setting, so
> the remaining piece would be restricting tab. (And perhaps holding
> shift to get to the console.. Hmm.) 
> 
> I would appreciate any suggestions :)
> 
> Thank you,--Ian 
> 
 
>From the perspective of a final user, breaking the prior behavior of 
directives needs to have very clear advantages.

The NOESCAPE (related to [esc]) and ALLOWOPTIONS (related to [tab]) 
directives have clear (and independent from each other) behaviors. 
Instead of changing their behaviors, the alternatives would be:
_ to find available workarounds (which was already proposed); or,
_ to add new directives.

IIRC, there are no "Global Directives" that apply to specific types 
of kernels or images but not to others (e.g. to modules but not to 
Linux), specially when they have no additional parameter. Introducing 
such type of additional classification could perhaps lead to more 
troubles than it's worth.

Considering that there is already a workaround available, I wonder if 
the inconvenience of having to add "too many" LABEL entries could be 
defeated by reorganizing your Syslinux configuration files.

For instance, using an initial cfg file with the "automatic" entries 
(those that don't require user interaction, such as whichsys.c32, 
ifcpu.c32...) and only then actually showing a [vesa]menu with the UI 
directive (in a second, in-common, cfg file). The individual 
configuration files can be then connected using directives such as 
INCLUDE and CONFIG (typical examples with multiple configuration 
files are available in ArchLinux and Debian, among others).

Regards,
Ady.