Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Background run and autostart portals don't work for unsandboxed apps #650

Closed
BrainBlasted opened this issue Oct 26, 2021 · 3 comments
Closed
Labels
backend specific This is an issue in implementations unsandboxed This only applies to unsandboxed applications

Comments

@BrainBlasted
Copy link

I'd been operating under the assumption that all portals work sandboxed and unsandboxed, since most portals I've used do. So in GNOME Clocks I recommended that a contributor use the portal, not knowing that it doesn't work for unsandboxed apps.

Ideally these portal APIs should work outside of the flatpak sandbox.

@TingPing TingPing added unsandboxed This only applies to unsandboxed applications backend specific This is an issue in implementations labels Oct 26, 2021
@vchernin
Copy link

I believe background and autostart not working are all consequences of #579

@stereomato
Copy link

hopefully this can be implemented for non-flatpak apps soon

@GeorgesStavracas GeorgesStavracas moved this to Needs Triage in Triage Oct 2, 2023
@GeorgesStavracas
Copy link
Member

For the Background portal in particular, so far nobody proposed a meaningful mechanism to identify apps - in contrast to services and arbitrary executables - when they're not executing under a sandbox. The good practice around portals is that we cannot simply rely on sensitive information generated by the app (e.g. we cannot use the app-id reported by the app). I think for now it's okay to consider the unsandboxed case as out-of-scope for the Background portal. Of course, if someone is able to come up with a reliable mechanism to detect such cases on the host system, and implements that on xdg-desktop-portal, it would be accepted.

@GeorgesStavracas GeorgesStavracas closed this as not planned Won't fix, can't repro, duplicate, stale Oct 3, 2023
@github-project-automation github-project-automation bot moved this from Needs Triage to Triaged in Triage Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend specific This is an issue in implementations unsandboxed This only applies to unsandboxed applications
Projects
Status: Triaged
Development

No branches or pull requests

5 participants