Application ID is empty when a host app uses portals #579
Comments
|
No portal methods take the application ID as argument. We can't let the untrusted application in the sandbox provide its own ID. It could by lying. We need the application ID to be provided from the outside, by flatpak |
Then I suppose
That is why I was thinking of using only handles from Wayland. Shouldn't it be really difficult to fake/steal information by design? If this was the case I don't see why we shouldn't trust a pseudo-random unique string. Chances of getting it right are probabilistically none. Plus: if an un-sendboxed application is using portals because of their convenience, shouldn't it be already untrusted and capable of doing bad things outside of portals (e.g. on Xorg alone)? Trying to make portals secure-by-design on host applications feels a bit like trying to bury our head in the sand. |
This sounds like a bug? Everything else you describe works as intended.
All connections to the portal implicitly, through a side-channel, contain the app_id of the connected process. This app_id is used to determine the permissions. An app_id as an argument to the portal is just like any other argument. In this case it is used to specify who to give permission to for a file that you have to proof you have access to. |
Mmmh I remember seeing a commit/merge request on some gitlab.gnome.org official repo that explicitly enabled this feature. I guess to inform the user which process is responsible for the inhibition? I don't know.
Ok. That clears that little doubt I had. Thanks for taking the time explaining me. As you may have understood I am pretty new to this interface. P.S. May I ask if you could please address my propositions as well? Were they so out-of-this-world? |
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)
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)
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)
In those methods the |
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)
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)
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)
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)
|
#719 fixes my use case for which I opened this issue. From my part this issue can be closed. |
|
Yeah, I don't think we need to cover this use-case for now. Properly spawning applications require some help from the compositor and the session manager these days, and that's primarily what we're trying to improve here. Thanks everyone for your work here. |
mwleeds
changed the title
Like the title says, I found myself in need (and will) to use the
Inhibitportal from a not yet flatpak-able application.Unlike many other portal methods
Inhibitdoesn't take anapp_idas parameter of the call, but the backend API presents it as a parameter without even specifying anywhere in the docs (I couldn't find it) thatapp_idis an empty string whenInhibitis used.xdg-desktop-portal/src/xdp-utils.c
Line 150 in 89d2197
This clashes with xdg-desktop-portal-gtk because Gtk requires a not-empty Application ID in order to grant the inhibition permission, making the usage of the portal practically unusable on GNOME by an host app.
From what @matthiasclasen told me, the portal relies on the unfakeable ID gotten from flatpak (or snap?) and not from the app-id specified in the program. The reason for this. as far as i know, appears to be that sometimes app id is used (by whom?) as a key for storing things and passing it outside of a sandbox could be a security threat.
Inhibit,ScreenshotorScreenCast, while for some others such asDocuments,FileChooser,AppChooserorPrintit isn't?xdp-utils.cwithout changing Inhibit's interface, would I be able to retrieve the app ID from the window's handle? If yes, how? I would be ok to start by doing it for Wayland's application windows only.gnome-session-inhibit)? I know the latter wouldn't be a beautiful solution, but it's better then denying it altogether.app_idis empty for some portal backend API? I have spent many hours investigating this problem and I would like if others didn't do my same mistake in the future.Why am I troubling so much using portals? I could just use XYZ!
The reason I want to use portals so bad is that I recently read more about them and I saw the hope of having a better interoperability between environments as possible. A standard that every app can follow and an easy way to manage apps' permissions.
That said, as far as I know, still many Flatpak apps don't fully use them, and thus many of them need more permissions than they should actually need.
I am really afraid that the situation won't change until portals become the de-facto standard. And a standard cannot be established if portals are used only by applications designed for Flatpak. And even if it did happen, many already-written apps might not see a re-implementation.
This is why, on my very little, I wanted to do my part and help a very common application (caffeine-ng, not yet flatpak-
able) to get closer to this more universal languageDemo
You can use my small Gtk4 test application as a demo: xdg-portal-inhibitor-test-gtk4.py
The text was updated successfully, but these errors were encountered: