Syslinux - Apr 2019 - Bug/limitation: allowoptions (for label), implicit (for automated)

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

> 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
 
 
For a very long time we have seen reports of "ALLOWOPTIONS" not being 
consistent or showing unclear / unexpected behavior(s).

So this is one additional report of ALLOWOPTIONS being buggy (at least 
since 5.00).

Independently of the problems with ALLOWOPTIONS, I'd like to point out 
that some of the examples provided are not "ideal".

Since version 5.00, kernel-like directives "should" refer to labels, 
rather than to a direct command. The same is true for the DEFAULT 
directive.

This would mean, for example:

###
DEFAULT mylabel

LABEL mylabel
LINUX mykernel
APPEND myoptions
###

instead of a direct command such as:

###
DEFAULT mykernel myoptions
###


In a  configuration file, adding options to one particular existing 
label could be achieved by more than one method:

###
DEFAULT mylabel

LABEL mylabel
LINUX mykernel
APPEND myoptions

LABEL add_options_w_cmdc32
COM32 cmd.c32
APPEND mylabel myadditionaloptions

LABEL add_options_wo_cmdc32
LINUX mykernel
APPEND myoptions myadditionaloptions
###

Similarly, the "conditional" c32 modules should expect labels rather 
than direct commands, as in:

###
LABEL conditionK
COM32 ifcpu.c32
APPEND 64 -- mylabel1 -- mylabel2

LABEL mylabel1
LINUX mykernel1
APPEND myoptions1

LABEL mylabel2
LINUX mykernel2
APPEND myoptions2
###

Of course, all the examples above can be combined in several ways.

Regarding the boot PROMPT, that's another matter, simply because the 
user could potentially type in whichever crap (s)he would want, so, in 
some sense, "expected syntax/parameters" is not really defined in such
case.

All my above comments are related to "expected behavior" when the 
_expected_ parameters (e.g. labels instead of direct commands) are used 
for each command/directive/module. If the cfg file uses "non-expected 
syntax", then I'm not sure how to define "expected behavior"
for such
situation.

Now, ALLOWOPTIONS should be thoroughly tested and every potential case 
should behave as expected (including misuse of whatever syntax is 
supposed to be "adequate" for whichever directive or command or c32 
module), whether it is in a cfg file or boot prompt or boot menu.

Regarding the ONERROR directive, I have never understood why it was 
designed to behave in the way it behaves. I could very well imagine a 
more useful behavior than the current one for this directive (but, if a 
different behavior were to be proposed, it would have to be implemented 
in a _new_ directive).

See also:
 www.syslinux.org/wiki/index.php/Cli 
 www.syslinux.org/wiki/index.php/Directives/special_keys
 www.syslinux.org/wiki/index.php/Directives/append 
 www.syslinux.org/wiki/index.php/Cmd.c32 

I can only hope that some Syslinux developer will eventually take a 
serious look at ALLOWOPTIONS and IMPLICIT.

Regards,
Ady.