Re: are posix-shell-compliant continuation lines valid/supported, or not, in /etc/default/grub ?

[Eli Schwartz]

On 3/19/20 8:57 PM, Dimitri John Ledkov wrote:
> Have you opened a launchpad bug report against the grub2 package with both
> configs before and after? What is the bug number there?
> 
> In general, we do parse and rewrite configs using debconf which is Perl / C
> / Shell processing using tools external to grub. In general, we advise to
> customize via grub.d drop-in files instead of modifying etc/default/grub
> file itself.
> 
> This is a bit out of scope for the upstream mailing list, as debconf
> integration is downstream specific on Ubuntu/Debian systems.
In general, other distros avoid parsing and rewriting configs because
this should be the user's responsibility. :p

The OP should consider that maybe such distros are more stable than Ubuntu?

...

Anyway, it seems clear-cut to me, as per the question which is NOT about
what should be done with debconf. The OP's question is very simple:

"Does the grub project consider /etc/default/grub as a shell-compatible
file which is sourced, to be the PUBLIC INTERFACE of this configuration
file?"

It seems clear-cut to me. The quoted manual section explicitly documents
that it is POSIX shell format, then calls out the idea of KEY=VALUE
assignments and declares this to be *merely* "normally", thus
highlighting the possibility that it isn't exclusively so.

Compare this to, for example, the os-release(5) man page which states
the following format for /etc/os-release:

"""
The basic file format of os-release is a newline-separated list of
environment-like shell-compatible variable assignments. It is possible
to source the configuration from shell scripts, however, beyond mere
variable assignments, no shell features are supported (this means
variable expansion is explicitly not supported), allowing applications
to read the file without implementing a shell compatible execution engine.
"""

Note how os-release(5) explicitly goes to some lengths to declare the
need for parsing this file in C, that it is *not* valid to simply use
shell code, and then continues on to enumerate which subset of shell
code it supports.

The conclusion is simple enough: if you are going to automatically
rewrite this grub file, you must do so using a parser engine that
implements POSIX shell and knows how to properly tokenize and rewrite
the full range of language features permitted by POSIX shell.

Doing otherwise is YOLO, rash, buggy, and prone to breakage as
demonstrated by the OP's bug report.

If a downstream project making use of grub, then goes ahead and calls
the use of backslash escapes for the very simple purpose of line
continuation across multiple lines (of all the things one might do in a
POSIX sh formatted configuration file, this is pretty tame), an issue of
"highly unusual abuse of POSIX shell semantics", this is pretty bad I
have to say. Also, it's victim blaming.

Just my $0.02 as a distro person (not a grub dev).

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

signature.asc
Description: OpenPGP digital signature