Relative `Path=` entries in .desktop files

[Sod.Almighty]

_______________________________________________
xdg mailing list
***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

[Sod.Almighty]

Hi everyone,

[Apparently formatted email is not acceptable on this mailing list. So
here is a plain text version.]

What happens if the Path= line of a *.desktop file is set to a relative
path? For example:

Path=mydir

Or:

Path=.

We at the AppImage project (https://github.com/probonopd/AppImageKit)
are wanting to use relative paths in *.desktop files to refer to
locations relative to the root of the application mount point. Please
see the github issue at
(https://github.com/probonopd/AppImageKit/pull/384#issuecomment-294278492)
for details.

What do you guys think? Would this create some kind of conflict with
existing path rules?

Cheers,
Stuart.

[Matthias Klumpp]

Post by Sod.Almighty
Hi everyone,
[Apparently formatted email is not acceptable on this mailing list. So here
is a plain text version.]

The list probably had an allergy against Comic Sans... (and I can't
blame it ;-) )

Post by Sod.Almighty
What happens if the Path= line of a *.desktop file is set to a relative
Path=mydir
Path=.

Nobody knows. Relative paths in .desktop files are not allowed by the
specification, so the implementations can straight out refuse to
launch anything, or do an arbitrary amount of undefined stuff, which
may include taking the .desktop file path as the basename and taking a
relative path from that, taking a relative path from $HOME, one from
the directory the desktop file was launched from, or doing something
completely different.
So: Don't do it.

=> https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables

Post by Sod.Almighty
The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment. The name or path of the executable program may not contain the equal sign ("="). Arguments are separated by a space.
We at the AppImage project (https://github.com/probonopd/AppImageKit) are
wanting to use relative paths in *.desktop files to refer to locations
relative to the root of the application mount point. Please see the github
issue at
(https://github.com/probonopd/AppImageKit/pull/384#issuecomment-294278492)
for details.
What do you guys think? Would this create some kind of conflict with
existing path rules?

Yes. Aside from that, I am not sure whether it's a good idea to allow
relative paths for security reasons. Changing the definition of Exec=
will take a really long time until all implementations follow the
changed spec, so that might not be practical.
From skimming through the bug report, I don't have any idea on what
actual problem you want to solve.
Can't AppImageKit use bindmount tricks to confine an application in an
environment with known paths? Or just rewrite the path at install time
to point to the right location?

Cheers,
Matthias

[Simon McVittie]

Post by Matthias Klumpp

Post by Sod.Almighty
We at the AppImage project (https://github.com/probonopd/AppImageKit) are
wanting to use relative paths in *.desktop files to refer to locations
relative to the root of the application mount point.

(I know this is not actually the original question, which was about
the Path key, not Exec; but the issues are somewhat similar.)

This has been discussed before in the threads starting at:
https://lists.freedesktop.org/archives/xdg/2014-September/013339.html
https://lists.freedesktop.org/archives/dbus/2014-September/016330.html

and then again at:
https://lists.freedesktop.org/archives/xdg/2016-June/013754.html
https://lists.freedesktop.org/archives/xdg/2016-July/013762.html
https://lists.freedesktop.org/archives/dbus/2016-June/016949.html

Please look at those threads before proceeding.

Summarizing, several people have asked for D-Bus .service files to support
relative paths (relative to *something*) in the Exec key, and I think the
semantics should be the same for .service and .desktop files.

The closest we had to consensus in previous threads seemed to be that
the people who wanted relative paths to work at all all wanted them to
be relative to the .desktop or .service file where the Exec line was
found, with an unresolved issue around what the definition is of
"the .desktop or .service file" if that's a symbolic link (resolving
relative to the symlink, or doing one level of dereferencing and resolving
relative to the referent, or dereferencing recursively and resolving
relative to the real file).

So, $prefix/share/applications/com.example.Foo.desktop would typically want
to have Exec=../../bin/foo in order to invoke $prefix/bin/foo, and
$prefix/share/dbus-1/services/com.example.Foo.service would have
Exec=../../../bin/foo to do the same thing.

However, some commenters expressed the opinion that relative paths should
be forbidden altogether, or should be introduced by some special magic
token like "Exec=$CURDIR/relative/path". I don't remember any particular
justification being presented for this.

I don't think filenames relative to $prefix are a good idea from the
point of view of the principle of least astonishment, because they are
not well-defined if the .desktop file is found in a location where the
root of the $prefix is not clear. For instance, imagine a tarball containing
a standalone app or game that unpacks to one of these layouts, with the
.desktop file not found in a share/applications directory:

root of archive
\- com.example.AngryBirds.desktop
\- bin
\- angry-birds
\- libs
\- libhelper.so

root of archive
\- bin
\- angry-birds
\- launcher
\- com.example.AngryBirds.desktop
\- libs
\- libhelper.so

.desktop files are basically the freedesktop equivalent of Windows .lnk
shortcuts - they can appear in a registry of known apps in
/usr/share/applications, but they can also be placed anywhere that the user
is expected to access with a file manager, as a "double-clickable" shortcut.

Exec=foo is well-defined already: it searches $PATH for foo, and is never
treated as relative. Locating an executable in the same directory as the
origin of the search path (same directory as the .desktop file, in the
previous proposal) would always have to be spelled "Exec=./foo".

If there is a need for Path to be relative, I think it would make most
sense to forbid Path=foo and require either Path=/absolute or
Path=./relative (more precisely, containing at least one path separator)
so that it works the same as Exec.

Post by Matthias Klumpp
I am not sure whether it's a good idea to allow
relative paths for security reasons.

What are those security reasons? I don't think it's a good design principle
to cite "security reasons" without some additional justification (which
threat model is in use and which attack is prevented).

Post by Matthias Klumpp
Can't AppImageKit use bindmount tricks to confine an application in an
environment with known paths? Or just rewrite the path at install time
to point to the right location?

For what it's worth, Flatpak does both of those: the application runs
in a mount namespace where its own prefix appears to be /app;
Flatpak rewrites the Exec line in "exported" .desktop files.

S