Session suspension and restoration protocol

[Simon McVittie]

On Wed, 20 Jun 2018 at 21:26:26 +0200, Roman Gilg wrote:
> On Mon, Jun 18, 2018 at 6:01 PM Simon McVittie <smcv at collabora.com> wrote:
> > When we discussed this on #gnome-hackers we were talking about doing
> > restoration by passing the restored session ID as platform_data to the
> > Activate method defined by
> > https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
> > which would mean that for trivial/stateless apps, it would be enough to
> > ignore it and just start up, which DBusActivatable implementations like
> > GtkApplication will already do. Is there a reason why you've opted to define
> > a new method instead?
> 
> I think it makes sense to have a separate method, because a client can
> dbus-activate with the protocol any dbus-activatable app. Imagine a
> rogue client tries to dbus-activate an app, which is not written to
> use this extension but provides the Activate method.

A rogue client, you say. What's the threat model here?

If the threat model is that clients can be malicious, it seems like the
worst-case is that a malicious client can tell the compositor to trigger
activation of an app that, when launched, does something undesirable
or dangerous without further user interaction. Are you relying on an
assumption that apps that do something undesirable or dangerous on
activation will never implement the state-restore protocol?

If the threat model is that clients can be malicious, then it seems
a bad idea to have an Exec= fallback code path, because running an
executable (with unexpected command-line arguments that it might
misinterpret or ignore) seems like just as plausible a way to do bad
things as calling Activate() on it.

I think the real problem here is that the compositor or session manager
doesn't necessarily have a secure way to associate Wayland clients with
their D-Bus identities. Perhaps this means the protocol used to register
for this service should be based on D-Bus, not Wayland? Systems for
running untrusted or partially-trusted apps already need to "firewall"
access to the D-Bus session bus (for example Flatpak knows how to
do this), and in particular they need to make sure that untrusted apps
can't own well-known names other than their own.

If the register_session_suspension request was replaced by a
RegisterSessionSuspension() D-Bus method, then the implementation of
that method in the compositor or session manager could check that the
method call sender (unique name) matches the current owner of the D-Bus
well-known name corresponding to the requested desktop ID. For example,
if it gets a method call from unique name ":1.123" asking it to restore
desktop_id = "org.gnome.Builder.desktop" later, then it could ask the
dbus-daemon who currently owns "org.gnome.Builder", and only continue to
process the method call if the answer is ":1.123".

I can't think of an equivalent for that setup that would be suitable for
an Exec= fallback path.

> In this sense the protocol should be extended with the information
> that the Restore method should also return an error, if the
> restoration id is not found.

In case you're not aware, D-Bus method calls can always raise an
error, which behaves a bit like a C++/Java/Python exception, and
happens instead of returning their documented "out" parameters (if
any). Erorrs have a mandatory machine-readable *name* and an optional
(but strongly recommended) human-readable *message*. If a particular
error situation is an important part of your protocol design, you
can document a specific error name to be used in that situation, for
example "org.freedesktop.SessionSuspension1.Error.RestoreNotImplemented".
Callers must be robust against error names that they do not understand,
which they should treat as meaning "there was some other error".

    smcv