Skip to content
Commit ced4fe30 authored by Phaedrus Leeds's avatar Phaedrus Leeds Committed by Georges Basile Stavracas Neto
Browse files

tree-wide: Rework handling of empty app IDs

As discussed in #581, we need to change how we handle
xdp_app_info_get_id() returning an empty string. Currently, this only
happens when the calling pid is unsandboxed (not Flatpak or Snap) so it
has so far been safe to assume that xdp_app_info_get_id() will return
the empty string if and only if xdp_app_info_is_host() returns TRUE.
However since we are about to add support for setting the app ID in
XdpAppInfo even for unsandboxed callers, we need to:
(a) Only use xdp_app_info_is_host() if the intention is to give
unsandboxed processes access to something, and
(b) Only check if the app ID is the empty string if we're doing so to
handle that case gracefully, e.g. by leaving out the app ID from a
user-facing message.

This commit does entail a slight change in behavior: for those portals
that use the app ID in the permission store even if the app ID is the
empty string, such as the wallpaper portal, the behavior before this
commit is that all unsandboxed apps share the same permission since the
empty string is used as the key. After this commit, only unsandboxed
callers for whom an app ID could not be determined share the same
permission (in other words granting a permission for one grants it for
all). I don't know if storing the empty string as the app ID in the
permission store is actually a good idea, but doing so is not a new
change in this commit, so if we want to change that we can do it
separately.
parent a0f991ff
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment