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.
Loading
Please register or sign in to comment