Relative `Path=` entries in .desktop files

[Simon McVittie]

On Sat, 15 Apr 2017 at 22:44:53 +0200, Matthias Klumpp wrote:
> 2017-04-15 22:05 GMT+02:00 Sod.Almighty <sod.almighty at gmail.com>:
> > 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.

> 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).

> 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