Interface for org.gnome.Mutter.IdleMonitor

snapcraft
1

I’m working on a snap for gnome-break-timer. Here’s a reference Flatpak manifest to get an idea what its sandbox needs to be shaped like: https://gitlab.gnome.org/GNOME/gnome-break-timer/-/blob/master/build-aux/flatpak/org.gnome.BreakTimer.Devel.json. So, it talks on these interfaces:

"--talk-name=org.gnome.ControlCenter",
"--talk-name=org.gnome.Shell",
"--talk-name=org.gnome.Mutter.IdleMonitor",
"--talk-name=org.gnome.ScreenSaver",
"--talk-name=org.freedesktop.Notifications"

Most of these are covered. We don’t need to worry about org.gnome.ControlCenter for this (that’s just for some error handling around the XDG Background portal), but the application does need to talk with org.gnome.Mutter.IdleMonitor. That’s an interface provided by Mutter that allows an application to see the session’s current idle time. It doesn’t look like there’s an existing snap interface I can use to talk with that dbus interface, and judging by the docs it looks like I should ask about that here, so here I am :slight_smile:

Here’s the complete error message when the application tries to use the idle monitor interface:

** (gnome-break-timer-daemon:52189): WARNING **: 16:02:10.090: MutterActivityMonitorBackend.vala:78: Error adding mutter idle watch: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.138" (uid=1000 pid=52189 comm="gnome-break-timer-daemon " label="snap.gnome-break-timer.daemon (enforce)") interface="org.gnome.Mutter.IdleMonitor" member="AddIdleWatch" error name="(unset)" requested_reply="0" destination="org.gnome.Mutter.IdleMonitor" (uid=1000 pid=42370 comm="/usr/bin/gnome-shell " label="unconfined")

Note that org.gnome.Mutter.IdleMonitor is one of many dbus names owned by GNOME Shell, so there are several other dbus objects related to it. Probably makes sense to be fine-grained with what this snap interface relates to, as I assume we’re doing with the screen-inhibit-control interface.

2

We’re not going to create an interface granting access to the org.gnome.Shell API, since it provides easy sandbox escape through its Eval method (pass an arbitrary JavaScript and have it executed by the gnome-shell process).

Maybe it would be worth trying to get a safe interface for this included in xdg-desktop-portal? It seems like the kind of thing that could fit as an extension of the existing org.freedesktop.portal.Inhibit.CreateMonitor method call, which delivers signals on session state changes. At the moment, it covers session close and screensaver activate/deactivate. Adding idle notification might fit in as another type of activity to monitor.

Some thought would need to be taken to ensure it doesn’t provide too fine grained information that could be used as a side channel.

3

Heh, that’s a charming feature :b Kudos for being on the look-out for these kinds of things! Incidentally, do you know if there is a bug report for that? (It’s concerning since there are dozens of apps on Flathub talking to GNOME Shell-attached dbus names). When you put it that way, it definitely makes sense to put that interface in a portal. I was wanting a less oddly specific name to talk to anyway.

Still, I’m a smidge confused. Looking at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/screen_inhibit_control.go, it appears it’s possible to specify a particular path (which makes sense, since GNOME Shell is also providing that screensaver interface). Or am I misunderstanding that?

4

Hi @dylanmccall, did you find solution for this? I’m using superproductivity on Ubuntu from Snap and it logs exactly this error. As a consequence, the “auto idle” feature doesn’t work.

5

No one asks interface for org.gnome.Shell API? org.gnome.Mutter.IdleMonitor API doesn’t have Eval method.

It will be really nice to get access to this API, it’s used in Telegram Desktop, specifically the GetIdletime method.

6

The Flatpak --talk-name directives in the first post in the thread would grant access to all of the shell APIs. Even if it was just --talk-name=org.gnome.Mutter.IdleMonitor, this would be the case because gnome-shell exports everything over a single D-Bus connection.

I’m still of the opinion that it’d be better to address this through an xdg-desktop-portal API. Most of the gnome-shell APIs haven’t been written with untrusted clients in mind, and a portal interface has the possibility of supporting non-GNOME desktops.

7

As far as I understand it’s just a list of his app’s flatpak permissions

Is this a problem given that snap’s AppArmor rules specify concrete object path and method names?

Otherwise your statement is also valid for the notifications, as they’re also provided by the shell, yet we have access to the notifications.
8

We’d need to expose substantially all of these methods/signals:

https://gitlab.gnome.org/GNOME/mutter/-/blob/main/data/dbus-interfaces/org.gnome.Mutter.IdleMonitor.xml

These are the sorts of things I’m concerned about:

  1. Can an application cause gnome-shell to misbehave if it calls AddIdleWatch a few million times?
  2. Can an application call RemoveWatch on IDs belonging to other applications and make them misbehave?
  3. Should an application be allowed to repeatedly call ResetIdletime to make the system always look busy?
1 Like
9

I guess only GNOME developers can answer these questions