Definition of command line in the Exec key

[Oswald Buddenhagen]

On Tue, Mar 28, 2017 at 06:45:58PM +0100, Simon McVittie wrote:
> On Tue, 28 Mar 2017 at 10:51:05 +0200, Oswald Buddenhagen wrote:
> > and in kde, it is even in fact - the evaluator is smart enough to use an
> > actual shell if the command gets too complex. but relying on that is
> > obviously unportable.
> 
> If you run it in an actual shell, do you filter/reject more complex
> syntax in some way, so that there's some hope that desktop files written
> by KDE users will be portable to other environments?
> 
that would presume an enviroment which is even more thorough than kde
in this regard (something that has historically not happened for all i
know), and yet we'd need to know the exact limits of said environment
(which means we'd have to implement at least the parser side of it).
this obviously makes no sense to me.

> > > If you need to use shell constructs like if...fi, ``, ${} then you
> > > must invoke a shell yourself:
> > > 
> > >     Exec=sh -c "if foo; then bar; else baz; fi"
> > > 
> > this is actually horrible advice, as it is pretty much guaranteed to
> > overtax the automatic quoting of expandos inside the nested command.
> 
> If by "expando" you mean "field code" in the desktop entry spec's jargon
> (%f and so on), that's fine: field code expansion inside a quoted argument
> is undefined behaviour according to the desktop entry spec anyway, so
> implementations are not required to do something sensible when they
> encounter it.
> 
one of the unfortunate things about the standard, because kde's
implementation exhibits perfectly guaranteed and safe behavior.

> (GLib's implementation substitutes field codes (wrapped in shell-style
> quoting) before doing shell-style parsing, so it is possible to get a
> "garbage in, garbage out" situation.)
> 
this is in effect comparable with kde's implementation, except that for
kde a smaller subset of possible inputs is garbage.

> > i find it unfortunate that the shared
> > subset which is considered valid is comparably small.
> 
> I think that's a feature more than a bug, actually: it means implementors
> are allowed to avoid using an actual shell (the implementation in GLib
> never does, and still isn't particularly large).

> "Don't ever run a shell" is a good way to be confident that you've
> avoided shell injection attacks.
> 
this is a non-argument unless you assume incompetence on the
implementor's side (which i guess would be mostly reasonable ;).
i for one will make the claim that my expander is safe for the
documented supported syntax. and outside it ... well, the user can
always just use sh -c to subvert any quoting guarantees.