[syslinux] Bug/limitation: allowoptions (for label), implicit (for automated)

Dany St-Amant dany.ephemeral.2014 at icloud.com
Sun Apr 21 18:43:07 PDT 2019


Hello,

At the boot prompt ALLOWOPTIONS 0 is only applied to implicit kernels and not to labels. For configuration which want to allow selection, but prevent customization of the kernel command line, this behaviour is bad.

Also the IMPLICIT 0 is applied to both the boot prompt and configuration setting (like DEFAULT); but one could argue that only the command supplied at the prompt make sense to be blocked by IMPLICIT 0.

*Example (default) current*
default kernelX OPT
# OPT not passed with allowoptions 0 (fully blocked with IMPLICIT 0)
default labelX OPT
# OPT currently passed regardless of allowoptions

*Example (ifcpu) current*
label conditionK
com32 ifcpu.c32
append 64 -- kernelX OPT1 -- kernelX OPT2
# same as above: OPT not passed with allowoptions 0 (fully blocked with IMPLICIT 0)
label conditionL
com32 ifcpu.c32
append 64 -- labelX OPT1 -- labelX OPT2
# same as above: OPT currently passed regardless of allowoptions

*Example (prompt) current*
kernelX OPT
# OPT not passed with allowoptions 0 (fully blocked with IMPLICIT 0)
labelX OPT
# OPT currently passed regardless of allowoptions

For the default/ifcpu case, it would make sense to ignore allowoptions, allowimplicit as the commands are from the configuration file. And for the prompt case, it would make sense to enforce allowoptions to both commands and apply allowimplicit to the implicit kernel invocation.

*Example (default) proposed*
default kernelX OPT
# invoked as is regardless of allowoptions and allowimplicit
default labelX OPT
# invoked as is regardless of allowoptions and allowimplicit

*Example (ifcpu) proposed*
label conditionK
com32 ifcpu.c32
append 64 -- kernelX OPT1 -- kernelX OPT2
# invoked as is regardless of allowoptions and allowimplicit
com32 ifcpu.c32
append 64 -- labelX OPT1 -- labelX OPT2
# invoked as is regardless of allowoptions and allowimplicit

*Example (prompt) proposed*
kernelX OPT
# OPT not passed with allowoptions 0 (fully blocked with IMPLICIT 0)
labelX OPT
# OPT not passed with allowoptions 0

One option is to change load_kernel() with an extra argument to know if the supplied command_line is provided via configuration or from the user. Then applied allowoptions, allowimplicit only if the cmdline is user_supplied (of course adding the support for allowoptions in the label path).

For command coming from the boot-once, could be considered as not being user_supplied as If one can use syslinux/extlinux to set the boot-once, one can likely also totally change the configuration file anyway. Safety/security here has to come from managing who can use the tools.

On the distinction of command coming from the user or not, the ONERROR command could be ignore for user supplied commands.

Not sure yet, if there's a need for yet another option to choose the behaviour between the current one and the one I think is the right one. For the behaviour of onerror, it might need such option, but onerror as other issue which require its own thread anyway.

What is the coding standard around changing public/exported API?

Regards,
Dany




More information about the Syslinux mailing list