On Sat, 15 Apr 2017 at 22:44:53 +0200, Matthias Klumpp wrote: > 2017-04-15 22:05 GMT+02:00 Sod.Almighty <[email protected]>: > > 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 _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
