AppInfo cleanups, pidfd based pid mapping, device portal removal #1281
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Ping. Anyone up for a review? |
swick
force-pushed
the
wip/pidfd
branch
2 times, most recently
from
10e6b2e to
fcea56b
Compare
|
Rebased onto #1281 which makes the tests work again. |
The Device portal is, to the best of our knowledge, not used by any component. It's also weird because it's not a portal expoed to clients which caused confusion. The service it provides is also provided by the permission store, minus the ability to map from arbitrary PID to an app id. This PID to app id mapping isn't something that can be done in general and is most likely broken when the PID is not of the xdg-dbus-proxy. Let's just remove it entirely.
One was a left-over and for the other we just removed the last users.
This will become useful once we support the dbus Containers1 interface and a new XDP_APP_INFO kind can still refer to a flatpak.
…fo_sync This will make it easier to follow which method of identiying an app will be used under what conditions.
Instead of returning either NULL with error, NULL without error and non-NULL without error, adhere to GLib convention and return either TRUE with an out param set or FALSE with an error set.
The org.fdo.DBus.GetConnectionCredentials method gives us both a PID (ProcessID) and a pidfd (ProcessFD) in one roundtrip. It fails when the PID can't be retrieved but allows the pidfd to be -1. The pidfd will become useful for host and Containers1 clients later.
Every app kind that can somehow get to a pidns of the calling process should be able to do the pid mappings. This will be used in the next commit.
Both host apps and snaps connect directly to dbus and thus have a pidfd that points to the calling process. This allows us to do pid mappings independent of the app kind. This will only work when the D-Bus broker supports pidfd (ProcessFD).
|
You need to update POTFILES.in as well: https://l10n.gnome.org/module/xdg-desktop-portal/#main |
|
@piotrdrag do you think it's possible to add such check as a CI step to this project? I think it's better if we make POTFILES.in being up-to-date a pre-condition to merging PRs |
|
Various projects in and around GNOME already do that, usually with a custom script or the long-abandoned intltool-update. I don’t know how the former works out, but |
|
Opened #1331 but if anyone has pointers at how to handle this well in CI I might add that as well... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pulled out from #1268. All the parts that can be merged right now without requiring the new dbus Containers1 interface.