Camera: use an empty app id in access dialog in case of empty app info

[grulja]

Sending an app id that doesn't resolve to valid app info (e.g. a desktop file is not found) will automatically reject camera request, because the backend is not able to verify whether the app (based on app id) runs in the background. This happens for example when you start Firefox in GNOME using Alt + F2 shortcut, where we get firefox" as app id from cgroups and since it doesn't find opened application window for "firefox", it automatically rejects the request. Using an empty id fixes this problem.

[swick]

The current version looks good to me

[grulja]

@jadahl any final word? If no, can you merge it? I seem to have power to do it myself, but probably shouldn't as I'm not a maintainer here :)

[jadahl]

Since this changes policy about how to deal with permissions (even though only for non-sandboxed apps), I think we should let it sit here for a few days. If no objections, then it can land.

[A6GibKm]

Would it make sense to add a app-id option to the options in AccessCamera?

[swick]

If we want to provide a way for apps to specify their app id (only when the app id cannot be inferred) then it probably makes sense to add a new interface just for that to avoid having to add it to every portal.

IOW, I think this is out of scope here.

[jadahl]

Indeed out of scope, right now, the app id is always inferred and never explicitly set by apps.

[A6GibKm]

Would a window handle improve the situation compared to an app-id? Anyways, yeah this is out of scope.

This MR looks good to me, but I missed an explanation of why the empty string fixes the issue.

[jadahl]

Would a window handle improve the situation compared to an app-id? Anyways, yeah this is out of scope.

Window handles are always about window management stacking order, i.e. placing a dialog on top of another window, which isn't needed here.

This MR looks good to me, but I missed an explanation of why the empty string fixes the issue.

It's to handle cases where one e.g. runs some app from a terminal and gets an cgroup that resolves to some bogus "app id". Detecting that and falling back to "" means the portal backend can handle it as "this is an unidentifiable app".