relative paths in Exec= in .desktop and .service files

[Simon McVittie]

On <https://bugs.freedesktop.org/show_bug.cgi?id=44030>, we've been
trying to work out what the semantics of a non-absolute Exec key in
D-Bus services should be. I would like it to be the same as in XDG
desktop entries (whatever that is), which is not currently completely
specified.

In particular, Ralf Habacker (maintainer of D-Bus on Windows) would like
D-Bus session .service files to be "relocatable", because fixed paths
like /usr are not something that exists on Windows. I would like to
avoid having the semantics of .service files on Windows and Unix be
completely different, so I would like to have something that can work on
Unix too, hence involving XDG rather than doing a Windows-specific change.

There are three cases:

1) absolute (starts with / on Unix, [/\] or [A-Za-z]:[/\] on Windows)

This is easy and obvious. Exec=/usr/bin/foo executes /usr/bin/foo,
Exec=C:\\mingw\\bin\\bar.exe executes C:\mingw\bin\bar.exe.

2) no path separator (no / on Unix, no [/\] on Windows)

For desktop entries on Unix, this is well-defined: Exec=foo searches the
PATH for foo, the same way execvp() would do.

For D-Bus services, this is not currently specified. Implementation
detail: dbus-daemon on Unix uses execv(), so it will look in its current
working directory, whatever that happens to be; dbus-daemon on Windows
fails to execute the service.

I think a reasonable behaviour would be to use execvp() on Unix and
SearchPath(NULL, "foo.exe", ...) on Windows.

3) contains a path separator but is relative

This is not currently in either specification: it is unspecified what
Exec=../bin/foo or Exec=./foo would do.

Reasonable possibilities include:

* it's relative to the directory containing the executable that is
interpreting the file, e.g. dbus-daemon[.exe], i.e. normally /usr/bin

* it's relative to the getcwd() of the process that is interpreting
the file, i.e. normally / or $HOME

* it's relative to the directory containing the file itself,
i.e. normally /usr/share/applications

(Implementation detail: whichever directory is chosen, on Unix, it
should be relatively straightforward to make Unix dbus-daemon chdir() to
it after fork() but before execvp(), since POSIX.1-2004 says chdir(2) is
async-signal-safe. That would make relative paths do the expected thing.)

Thoughts?

Regards,
S

[Simon McVittie]

Post by Simon McVittie
3) contains a path separator but is relative
This is not currently in either specification: it is unspecified what
Exec=../bin/foo or Exec=./foo would do.
* it's relative to the directory containing the executable that is
interpreting the file, e.g. dbus-daemon[.exe], i.e. normally /usr/bin

I think this is probably the most useful set of semantics for
relocatable applications.

One additional open question here: if the executable is a symlink, is
the path relative to the location where it was found, or the "real path"?

Post by Simon McVittie
* it's relative to the getcwd() of the process that is interpreting
the file, i.e. normally / or $HOME

This is awkward for relocatable applications, since the current working
directory is not particularly predictable; it can be worked around by
making the process that is interpreting the file (e.g. gnome-session or
dbus-daemon) chdir() into a known location, such as the directory
containing its executable, but then that chdir() becomes de facto API.

Post by Simon McVittie
* it's relative to the directory containing the file itself,
i.e. normally /usr/share/applications

This is more annoying for relocation because ${prefix} and
${exec_prefix} might differ, but it's easy to explain (and consistent
with, e.g., HTML links).

The same question about symlinks applies.

S

[Simon McVittie]

Post by Simon McVittie
3) contains a path separator but is relative

...
[...]

Post by Simon McVittie
* it's relative to the getcwd() of the process that is interpreting
the file, i.e. normally / or $HOME

According to
<https://unix.stackexchange.com/questions/144422/getting-the-current-path-in-desktop-exec-command>,
this is what happens in KDE.

Post by Simon McVittie
* it's relative to the directory containing the file itself,
i.e. normally /usr/share/applications

According to
<https://unix.stackexchange.com/questions/144422/getting-the-current-path-in-desktop-exec-command>,
this is what happens in Cinnamon and probably GNOME.

S

[Thiago Macieira]

Post by Simon McVittie
* it's relative to the directory containing the executable that is
interpreting the file, e.g. dbus-daemon[.exe], i.e. normally /usr/bin
* it's relative to the getcwd() of the process that is interpreting
the file, i.e. normally / or $HOME
* it's relative to the directory containing the file itself,
i.e. normally /usr/share/applications

The first two options might be valid for D-Bus and dbus-daemon, but they can't
be for the desktop file specification since there are multiple processes
processing them, which means a wide variety of CWD and of installation
prefixes. Desktop files should be predictable, so I'd suggest we go for the
third option: relative to the file itself.

[Ryan Lortie]

hi,

Post by Thiago Macieira
The first two options might be valid for D-Bus and dbus-daemon, but they can't
be for the desktop file specification since there are multiple processes
processing them, which means a wide variety of CWD and of installation
prefixes. Desktop files should be predictable, so I'd suggest we go for the
third option: relative to the file itself.

I agree.

If we are to support this (which is still an open question, imho) then
this is really the only way.

(nitpick) I assume you mean "relative to the directory in which the file
was found".

Cheers

[Jon Watte]

My proposal is that a relative entry should be specified to "fail to
execute."
Unless there is a really, really good use case (other than "users sometimes
mistakenly write this") then there's no reason to allow any kind of
ambiguity.

Sincerely,

jw







Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas
Jefferson

On Mon, Sep 8, 2014 at 5:23 AM, Simon McVittie <

Post by Simon McVittie
On <https://bugs.freedesktop.org/show_bug.cgi?id=44030>, we've been
trying to work out what the semantics of a non-absolute Exec key in
D-Bus services should be. I would like it to be the same as in XDG
desktop entries (whatever that is), which is not currently completely
specified.
In particular, Ralf Habacker (maintainer of D-Bus on Windows) would like
D-Bus session .service files to be "relocatable", because fixed paths
like /usr are not something that exists on Windows. I would like to
avoid having the semantics of .service files on Windows and Unix be
completely different, so I would like to have something that can work on
Unix too, hence involving XDG rather than doing a Windows-specific change.
1) absolute (starts with / on Unix, [/\] or [A-Za-z]:[/\] on Windows)
This is easy and obvious. Exec=/usr/bin/foo executes /usr/bin/foo,
Exec=C:\\mingw\\bin\\bar.exe executes C:\mingw\bin\bar.exe.
2) no path separator (no / on Unix, no [/\] on Windows)
For desktop entries on Unix, this is well-defined: Exec=foo searches the
PATH for foo, the same way execvp() would do.
For D-Bus services, this is not currently specified. Implementation
detail: dbus-daemon on Unix uses execv(), so it will look in its current
working directory, whatever that happens to be; dbus-daemon on Windows
fails to execute the service.
I think a reasonable behaviour would be to use execvp() on Unix and
SearchPath(NULL, "foo.exe", ...) on Windows.
3) contains a path separator but is relative
This is not currently in either specification: it is unspecified what
Exec=../bin/foo or Exec=./foo would do.
* it's relative to the directory containing the executable that is
interpreting the file, e.g. dbus-daemon[.exe], i.e. normally /usr/bin
* it's relative to the getcwd() of the process that is interpreting
the file, i.e. normally / or $HOME
* it's relative to the directory containing the file itself,
i.e. normally /usr/share/applications
(Implementation detail: whichever directory is chosen, on Unix, it
should be relatively straightforward to make Unix dbus-daemon chdir() to
it after fork() but before execvp(), since POSIX.1-2004 says chdir(2) is
async-signal-safe. That would make relative paths do the expected thing.)
Thoughts?
Regards,
S
_______________________________________________
dbus mailing list
http://lists.freedesktop.org/mailman/listinfo/dbus

[Thiago Macieira]

Post by Jon Watte
My proposal is that a relative entry should be specified to "fail to
execute."
Unless there is a really, really good use case (other than "users sometimes
mistakenly write this") then there's no reason to allow any kind of
ambiguity.

Simon's email explained the use-case: relocatable installations, especially on
Windows.

[Jon Watte]

Post by Thiago Macieira
Simon's email explained the use-case: relocatable installations, especially on
Windows.

I don't think that's strong enough to open up a security can of worms.
If you want relocation, use some token system (like how Scons has "#" for
"root of build")
And if the main use case is for Windows, then again I'd look carefully at
actual numbers of users/installs and ability to capture that market, and
discount the value of that support appropriately.
Maybe not everyone agrees with that sentiment, but it's a largely
observable truth :-)

Sincerely,

jw





Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas
Jefferson

Post by Thiago Macieira

Post by Jon Watte
My proposal is that a relative entry should be specified to "fail to
execute."
Unless there is a really, really good use case (other than "users

sometimes

Post by Jon Watte
mistakenly write this") then there's no reason to allow any kind of
ambiguity.

Simon's email explained the use-case: relocatable installations, especially on
Windows.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Thiago Macieira]

Post by Jon Watte

Post by Thiago Macieira
Simon's email explained the use-case: relocatable installations, especially on
Windows.

I don't think that's strong enough to open up a security can of worms.
If you want relocation, use some token system (like how Scons has "#" for
"root of build")
And if the main use case is for Windows, then again I'd look carefully at
actual numbers of users/installs and ability to capture that market, and
discount the value of that support appropriately.
Maybe not everyone agrees with that sentiment, but it's a largely
observable truth :-)

If you feel there are security implications, please say so. If there are
issues, then the desktop spec needs to address them one way or another. We
could choose one of Simon's three suggestions or outright ban the practice.
But all desktops need to be fixed to deal with this correctly.

I also fail to see how having a token is any better than declaring relative
paths to be searched from $PWD. Can you shed more light on this suggestion?

In any case, D-Bus would like to follow the same specification as .desktop
files, but it could diverge if necessary to meet its unique requirements.

[Jon Watte]

Post by Thiago Macieira
I also fail to see how having a token is any better than declaring relative
paths to be searched from $PWD. Can you shed more light on this suggestion?

$PWD is something that a user or administrator may change for many
different reasons, not to mention it's different per-user. Relying on this
for dbus invocation may lead to all kinds of hard-to-debug surprises and
perhaps open up attack vectors.
Tying yet-another-thing into that same environment value means that you tie
more opportunities for failure into a thing users typically fiddle with.
If the goal is to support alternative or non-standard or isolated installs
of dbus, then having one place that defines what "search start" means FOR
THAT INSTALL would be the most robust and secure solution,.
On Windows, that might be a registry value that is specific to dbus.
On Linux, that could be a symlink in /etc/alternatives, for example. (This
is an illustrative example, not a soup-to-nuts considered proposal)

However, I think the system would be simpler and more secure if relative
search just didn't exist. If the only actual, needed-right-now, reason to
introduce relative search is for Windows support, then I don't think that
use case is important enough to relax the potential security and complexify
the implementation and administration.

Sincerely,

jw








Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas
Jefferson

Post by Thiago Macieira

Post by Jon Watte

Post by Thiago Macieira
Simon's email explained the use-case: relocatable installations, especially on
Windows.

I don't think that's strong enough to open up a security can of worms.
If you want relocation, use some token system (like how Scons has "#" for
"root of build")
And if the main use case is for Windows, then again I'd look carefully at
actual numbers of users/installs and ability to capture that market, and
discount the value of that support appropriately.
Maybe not everyone agrees with that sentiment, but it's a largely
observable truth :-)

If you feel there are security implications, please say so. If there are
issues, then the desktop spec needs to address them one way or another. We
could choose one of Simon's three suggestions or outright ban the practice.
But all desktops need to be fixed to deal with this correctly.
I also fail to see how having a token is any better than declaring relative
paths to be searched from $PWD. Can you shed more light on this suggestion?
In any case, D-Bus would like to follow the same specification as .desktop
files, but it could diverge if necessary to meet its unique requirements.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Thiago Macieira]

Post by Jon Watte

Post by Thiago Macieira
I also fail to see how having a token is any better than declaring relative
paths to be searched from $PWD. Can you shed more light on this suggestion?

$PWD is something that a user or administrator may change for many
different reasons, not to mention it's different per-user. Relying on this
for dbus invocation may lead to all kinds of hard-to-debug surprises and
perhaps open up attack vectors.

That's exactly what I suggested we *not* do.

I suggested that it be relative to where the .desktop file is. That means all
applications and all users accessing the same .desktop file will have the same
behaviour.

I misspoke when I said $PWD. I was probably thinking of qmake project files,
where $$PWD expands to "directory where I found the project file".

Post by Jon Watte
Tying yet-another-thing into that same environment value means that you tie
more opportunities for failure into a thing users typically fiddle with.
If the goal is to support alternative or non-standard or isolated installs
of dbus, then having one place that defines what "search start" means FOR
THAT INSTALL would be the most robust and secure solution,.
On Windows, that might be a registry value that is specific to dbus.
On Linux, that could be a symlink in /etc/alternatives, for example. (This
is an illustrative example, not a soup-to-nuts considered proposal)
However, I think the system would be simpler and more secure if relative
search just didn't exist. If the only actual, needed-right-now, reason to
introduce relative search is for Windows support, then I don't think that
use case is important enough to relax the potential security and complexify
the implementation and administration.

Does this clarification change your answer?

Because I don't see how this suggestion adds a security issue.