Desktop Entry Specification is missing [ as a reserved character in Exec

[Bollinger, John]

On Tuesday, June 25, 2024 2:32 AM, meator <meator.dev at gmail.com> wrote:

> Before I react, I should mention that you appear to be replying to me
> specifically and not to the mailing list.

Oops.

> I do not know whether this is
> intentional or not, but I will assume it is and I will not CC the
> ​mailing list. But it would be nice if this discussion would be included
> in the mailing list to allow others to react to it.

I include the list this time.

> On 6/20/24 16:36, Bollinger, John wrote:
> > Hello,
> >
> > The spec is less than forthcoming about the purpose for quotation in the
> > values of Exec keys.  On one hand, the spec says that the value of an
> > Exec key should be a "command line", and the rules for it do seem
> > consistent with handing off the command to a shell for execution. On the
> > other hand, the spec doesn't actually require "command lines" to be
> > executed via a shell at all, and if they were, the spec doesn't say
> > which one or even which family of them.  It makes no promise that any
> > redirections or command-line expansions that a shell might perform will
> > in fact be done, except that it does require quote removal and
> > protection of erstwhile quoted arguments from being split into multiple
> > arguments afterward.
>
> [...] I am well aware of the ambiguity of the specification. I
> have assumed that this ambiguity is intentional, that the authors of the
> specification choose to not specify how exactly shall the program is
> executed. [...]

That's plausible, and I have considered the possibility myself.

> I have also messaged this mailing list about this
> (See "A few questions about escaping in desktop files" sent in 22.
> August 2022). In this thread, I was assured that the implementation can
> either choose to do word splitting and unquoting itself or it can pass
> the job to a shell.

I do not find that surprising, but the spec really ought to be clear about it.
And it should present the quoting rules as a consequence of that freedom,
not standalone requirements. That would have mooted the present discussion,
and if implemented, it might yet moot some future ones. Something like this,
for example:

---

The Exec key

The Exec key must contain a command line. A command line consists of
an executable program name, optionally followed by one or more arguments,
all separated from each other by unquoted spaces. The program
name can be specified either as an absolute path or as a simple name,
without any path. If no path is provided then the executable is identified by
Looking it up in the executable search path used by the desktop environment.

The program name and arguments may each be quoted in whole, by enclosing
them in double quotes and escaping any double-quote characters within.
Arbitrary other characters may be escaped as well (see also below).

The desktop environment is permitted to execute command lines by
presenting them as literal input to the system's default shell (/bin/sh), by
parsing the command line itself and exec()ing the result, or by other, similar
means of its choosing.  Therefore, commands must be quoted and escaped
such that their interpretation according to the shell's rules does not
differ from their interpretation according to the more limited delimiting,
quoting, and escaping rules presented in this specification. Among the
implications are:

 - if the program name contains an equals sign ("=") then either it must
   be quoted or the equals sign must be escaped.
 - the program name must be quoted or escaped if it is a shell reserved word
   ("!", "{", "}", "case", "do", "done", "elif", "else", "esac", "fi", "for", "if", "in",
   "then", "until", "while").
 - Where the program name or any argument starts with a tilde ("~")
   character, either the whole must be quoted or the tilde must be escaped.
 - shell metacharacters and operators anywhere in the command line must be
   quoted or escaped. For this purpose, it suffices to quote or escape every
   appearance of each of these characters: vertical bar ("|"), ampersand ("&"),
   semicolon (";"), parentheses ("(" and ")"), less-than sign ("<"),
   greater-than sign (">"), tab, newline, and spaces (other than those meant
   to separate the program name and arguments from each other).
 - The double quote (when representing itself), backslash ("\"), dollar
   sign ("$"), and backtick ("`") characters anywhere in the command line
   must be escaped.  Quoting these is not sufficient.
 - The comment-start ("#") and single quote ("'") characters appearing
   anywhere in the command line must be quoted or escaped.
 - Characters and character combinations meaningful for pathname
   expansion must be quoted or escaped anywhere they appear in the
   command line.  These include the asterisk ("*"), question mark ("?"),
   and matched pairs of square brackets ("[", "]").

Note that the general escape rule for values of type string also states that
the backslash character can be escaped as ("\\"), and that this escape rule
is applied before the quoting rule. As such, to represent a literal
backslash character in a quoted argument in a desktop entry file requires
the use of four successive backslash characters ("\\\\"). Likewise, a literal
dollar sign in a quoted argument in a desktop entry file is represented
with ("\\$").

[... field codes ...]

---

> [...]  the
> [ character is missing from the reserved characters, which means that
> all implementations using the shell for execution very likely result in
> unintended behavior for desktop files which contain [ in an unquoted
> argument of Exec.

Possibly. [ itself is a standard external command, equivalent to "test".
It is used frequently for that purpose in shell conditional commands.  And
even when not appearing as a command name, unquoted [ still represents
itself unless paired with a matching ].  I speculate that that may explain why
[ is not on the must-be-quoted list.  But that would be another good reason
for being more explicit about how the Exec key can be used, and to discuss
quoting in that context, instead of as standalone requirements.


Best,

John Bollinger



________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20240625/829eb532/attachment-0001.htm>