[syslinux] Issues with syslinux_run_command(str) and parameters

[Ian Bannerman]

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