Exec in .desktop (was Re: Security issue with .desktop files revisited)

[Vincent Untz]

Le vendredi 07 avril 2006 à 10:37 +0200, Francois Gouget a écrit : 
> Hi,
> 
> Vincent Untz wrote:
> [...]
> >>>>Not even. First KDE, at least, lets you specify multiple commands
> >>>>separated by semi-colon so you could drop the 'sh -c':
> >>>>
> >>>>Exec=/usr/X11R6/bin/xeyes;/usr/X11R6/bin/xeyes
> >>>
> >>>Wow. Does the spec allow this?
> 
> Ok, I've found it again:
> 
>   * the Desktop Entry Specification says:
>     http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
> 
>  > Some keys can have multiple values; these should be separated by a
>  > semicolon. Those keys which have several values should have a
>  > semicolon as the trailing character. Semicolons in these values need
>  > to be escaped using \;.
> 
> In practice I find that keys that have several values rarely have a 
> trailing ';' but that's not relevant here. What's relevant is that it 
> does not say that regular strings are not allowed to contain a 
> semi-colon. On the contrary:
> 
>   * the Desktop Entry Specification says that the Exec field value is 
> 'string'.
> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s04.html

If you look closely at the table, you'll notice that some keys have
"string(s)" for type. My interpretation is that only those keys can have
separate values. But as you point you, this is not really relevant here.

>     and
> 
>  > Values of type string may contain all ASCII characters except for
>  > control characters.
> 
>     So there is no restriction about ';', '|', '&', etc.

Right. And why should there be? If I want to create a launcher to open
the "Ilovesemicolons;;;.txt" with gvim, then why not? The alternative is
to escape the semicolons (so I'd have to put "gvim Ilovesemicolons\;\;
\;.txt"). A better example might "Mom&Dad.txt".

>   * finally, about the Exec field it says:
>     http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
> 
>  > The escaping of the exec parameters is done in the way the mailcap
>  > specification describes. Take a look at RFC 1524  for more
>  > information.
> 
>   * so I looked at RFC 1524 but I did not find the word 'escap*' 
> anywhere in it. However I believe that what the Desktop Entry 
> Specification meant was that the 'Semantics of executable commands' 
> section applies to the Exec field. That section says:
>     http://www.ietf.org/rfc/rfc1524.txt
> 
>  > On a UNIX system, such commands will each be a full shell command
>  > line, including the path name for a program and its arguments.
>  > (Because of differences in shells and the implementation and behavior
>  > of the same shell from one system to another, it is specified that
>  > the command line be intended as input to the Bourne shell, i.e., that
>  > it is implicitly preceded by "/bin/sh -c " on the command line.)

Indeed. So this is legal for RFC1524.

> So from that I deduce that it is legal to use the following in the Exec 
> field:
> 
> Exec=command1;command2 || command3
> 
> And that it will behave like
> 
> sh -c "command1;command2 || command3"
> 
> 
> But I might be wrong in how I understand the RFC 1524 to apply to the 
> Desktop Entry Specification. It is quite ambiguous there. In particular 
> the 'Semantics of executable commands' also says that if there is no 
> '%s' on the command line, then the content of the file will be passed 
> through stdin and I doubt that part to apply to the Desktop Entry 
> Specification...

I really think we should work on fixing this: it shouldn't be ambiguous
at all.

My main issue about making it legal to use the shell syntax here is that
some users with no shell knowledge will create launchers and wonder why
it does not work. And I don't think we should force people who don't
know about the shell to learn all this. On the other hand, people
wanting to achieve this and who realize it doesn't work should be
knowledgeable enough to put use "sh -c".

However, we already force people to know that they should use escape
spaces...

Vincent

-- 
Les gens heureux ne sont pas pressés.