[syslinux] Issues with syslinux_run_command(str) and parameters

[Ian Bannerman]

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