Get app ID via libsystemd for unsandboxed apps #719
Conversation
|
We probably need to do something like what gnome-shell does but the algorithm there is pretty complicated: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/src/shell-window-tracker.c#L380-468 |
|
Some notes from @refi64 on this topic:
|
|
To me this looks like an issue with gnome-software. The file it installs in The question I have however is why this is relevant. Shouldn't the portal be able to work with an appid of |
I feel like that is the situation as well. Gnome Software doesn't seem to follow the XDG standardization for application. Either because of the .desktop file name or, perhaps, it doesn't set the
yes, indeed. (?) Since we are talking about an un-sandboxed app it doesn't seem to be that relevant... EDIT: wait, browsing Gnome Software repo i see they expect 3
could it be that the autostarted service is not an actual GUI application? Should it really be associated with the AppID |
Yes, The reason we need the correct app ID, |
|
Mmh I see. Just one more question I can't answer since at the moment I'm not on Gnome: I don't fully understand what happens when In case that it changes, shouldn't the background service be identified as a |
When you launch
I don't know of any way to make that happen, but even if we could, we want the correct app ID even when Software is running in the background. Portal operations are generally in response to user interaction but it's not inconceivable we would need to use x-d-p in the background, and certainly we would at least connect to the D-Bus service even if we didn't call any methods. |
Urgh, yeah, so this is not a problem in principal just a weird whitelist case.
Not in this case, if you start gnome-software from shell it it will find the running instance, tell it to open a window and then exit.
Was this actually a conscious decision? They are after all the same application, the autostart desktop file just starts it in the background. |
|
I proposed a rename of the autostart desktop file: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1261 It looks like |
The hypothetical scenario I mentioned was that the autostart launcher was disabled by the user, and in that case there would be no running instance to find. |
Currently we install three .desktop files: - org.gnome.Software.desktop which is the one used for the shell's list of applications - gnome-software-local-file.desktop which is used for opening local files - gnome-software-service.desktop which is put in /etc/xdg/autostart/ so that "gnome-software --gapplication-service" is run in the background at the start of a user session. This commit renames the autostart one to org.gnome.Software.desktop. This change is necessary so that the systemd scope created for gnome-software will follow the standard laid out by https://systemd.io/DESKTOP_ENVIRONMENTS/ which says that the Application ID should be in the unit name. With this change the scope goes from e.g. "app-gnome-gnome\x2dsoftware\x2dservice-9502.scope" to e.g. "app-gnome-org.gnome.Software-2248.scope". Both before and after this commit, the scope and process are the same for the background service and for the graphical application when/if it is launched. Having the scope (cgroup) in the right format is important because I am working on getting xdg-desktop-portal to use the cgroup of a process to determine its app ID[1], and the app ID is then used for checking permissions, including in the dynamic launcher portal which will specifically allow the app ID "org.gnome.Software" for one of its methods.[2] An interesting historical note: gnome-software-service.desktop used to have "Exec=${libexecdir}/gnome-software-service" before "--gapplication-service" came along, so it used to make more sense that it was named as such. I have tested this change; starting gnome-software in the background and via gnome-shell work as expected. [1] flatpak/xdg-desktop-portal#719 [2] flatpak/xdg-desktop-portal#696
mwleeds
force-pushed
the
mwleeds/app-id-via-systemd
branch
from
800e7e7
to
8a11540
Compare
mwleeds
force-pushed
the
mwleeds/app-id-via-systemd
branch
2 times, most recently
from
126e302
to
329d8bf
Compare
Even with that change the cgroup does not contain the app ID when the app is launched from the command line: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1261#note_1398950 I don't think that's necessarily a blocker for merging this but it makes development hard. |
yes, the systemd specification is tailored for desktop environments. If you want to launch a program from terminal such that it complies with the xdg systemd & DE specification you have to do it as described in this snippet: https://invent.kde.org/-/snippets/1111 I'd say it's still worth it to push the MR on Gnome Software |
mwleeds
force-pushed
the
mwleeds/app-id-via-systemd
branch
from
e5c886f
to
79d13d3
Compare
|
(force-pushed to rebase on main) |
mwleeds
force-pushed
the
mwleeds/app-id-via-systemd
branch
from
79d13d3
to
0942cb0
Compare
There was a problem hiding this comment.
This PR continues to LGTM, the tests are chef's kiss. @hadess should we land this? This is blocking further portals.
This commit adds an optional dependency on libsystemd and, when available, uses it to attempt to find an application ID even for processes which are not Snap or Flatpak sandboxes. This is not always successful, so we still need to handle the case of an empty app ID for an XdpAppInfo. Since this is not a perfect solution for finding the app ID, we may eventually want to introduce a way for *unsandboxed* processes to specify their own app ID, perhaps a portal-wide SetAppID() method. This is analogous to the security model gnome-shell has: if a process is sandboxed use that app ID, and otherwise use information that is under the control of the application (e.g. WM_CLASS, GApplication ID, etc.). Helps: #579 (Originally authored by Carlo Castoldi, re-done by Phaedrus Leeds)
GeorgesStavracas
force-pushed
the
mwleeds/app-id-via-systemd
branch
from
0942cb0
to
7b8af12
Compare
This is a rework of #581 and dependent on #718, but I'm marking it as a draft because sadly it doesn't work for the one case I actually need it: GNOME Software.
In the case of, say, non-Flatpak Epiphany, the app ID can be successfully gleaned from the systemd unit which looks like
app-gnome-org.gnome.Epiphany-182352.scope. But in the case of gnome-software (which runs as/usr/bin/gnome-software --gapplication-service) the unit looks likeapp-gnome-gnome\x2dsoftware\x2dservice-9502.scope(where 9502 is the pid in my case) so parsing that in any way is not going to get us the correct app ID oforg.gnome.Software. So I think we need to look for a better way to get app IDs...