Migrating to GTK4

[ben.boeckel]

Hi,

I’m looking to migrate systemd-gnome-ask-password-agent to GTK4. The current stumbling block I’m running into is GtkStatusIcon’s deprecation. The docs state that GNotification is the intended replacement, which is…fine. Before I go down the road of making a GtkApplication and such, is there a better migration path for this program? It doesn’t use a main window at all, so more than half of GtkApplication’s over GApplication seems excessive, but then it also does the action thing for me automatically. Is there another path I should head down instead?

Thanks.

[lb90]

Hi @ben.boeckel,

That can be done, but it’s not that great from a security perspective. First, consider that ask-password agents run as privileged services. Running GUI toolkits as privileged accounts is not ideal, as the attack surface becomes quite larger. That can be solved easily: just spawn an unprivileged subprocess to show the GUI! However there remain two problems:

1. GTK is a general-purpose GUI toolkit. It can load plugins (depending on environment variables), it parses input files, etc. Your GUI application will handle sensitive data, and a malicious plugin could steal personal info. Using a locked-down GUI toolkit (like the Shell Toolkit in GNOME) would be better, because it’s geared towards higher security.
2. Generic apps do not have much isolation. That may have changed with Wayland, but on X11 every client can install keyloggers. On Linux, GUIs that handle sensitive data are generally shown by the Shell, which is a special client and has the needed isolation.

[lb90]

And now to your question

You should use GApplication as it’s a prerequisite for GNotification. I think you’ll have to call g_application_hold so that the agent can keep running. The agent can send notifications whenever it detects changes in /run/systemd/ask-password/. You’ll also need a .desktop entry as described in Gio.Notification. The agent will be notified whenever a notification is activated by the user, and at that time you can show a dialog (either in-process or by spawning a dedicated subprocess).

Do you know if agents run on the system bus or the session bus?

[ben.boeckel]

@lb90

First, consider that ask-password agents run as privileged services.

I’m not running it with any special permissions. The required elevation to answer system-wide queries is handled via polkit rules: systemd-ui/systemd-gnome-ask-password-agent.rules at modernize-metadata-wip · mathstuf/systemd-ui · GitHub.

If this is still not recommended, I guess I’ll look for a way to work with river (my intended Wayland compositor at the moment).

Also, systemd 257 supports user-level password agents:

@https://systemd.io/PASSWORD_AGENTS/

Unprivileged Per-User Password Agents

Starting with systemd v257 the scheme is extended to per-user password agents. A second per-user directory $XDG_RUNTIME_DIR/systemd/ask-password/ is now available, with the same protocol as the system-wide counterpart. Unprivileged, per-directory agents should watch this directory in parallel to the system-wide one. Unprivileged queriers (i.e. clients to these agents) should pick the per-user directory to place their password request files in.

@lb90

Do you know if agents run on the system bus or the session bus?

There’s no D-Bus requirement; inotify(7) is sufficient.

[lb90]

Ah ok, I take back all my warnings about security. The architecture is looking quite good from a security standpoint!

GtkApplication is the way to go. Just call GApplication.hold() so that the agent keeps running indefinitely.