USB portal (cont.) #1354

hfiguiere · 2024-04-30T02:32:36Z

This supercede #1238

Close #1238

hfiguiere · 2024-08-15T02:33:44Z

After a painful rebasing.

hfiguiere · 2024-09-14T03:06:35Z

Feature is linked to flatpak/flatpak#5620

I think this is ready for review.

swick

Checked the bits outside of usb.c so far.

src/xdp-app-info-flatpak.c

src/xdp-utils.h

swick · 2024-09-17T10:59:51Z

src/xdp-app-info-flatpak.c

+
+      enumerable_devices = g_key_file_get_string_list (app_info_flatpak->flatpak_info,
+                                                       "USB Devices",
+                                                       "allowed-devices",


enumerable-devices/hidden-devices

Might want to use defines for those constants.

fixed the literal.

src/xdg-desktop-portal.c

src/xdp-utils.c

swick

Bunch of comments on the interface definition. Mostly about documentation but I'm a bit worried about what device removal means and how we should deal with udev properties.

data/org.freedesktop.portal.Usb.xml

swick · 2024-09-17T12:21:46Z

data/org.freedesktop.portal.Usb.xml

+
+        * ``properties`` (``a{sv}``)
+
+          A list of udev properties that this device has. These properties


I'm really worried about this. It essentially makes udev a stable API even though it really is not.

swick · 2024-09-17T12:25:16Z

data/org.freedesktop.portal.Usb.xml

+        This method can only be called once, and only after calling
+        org.freedesktop.portal.Usb.AcquireDevices().


Should mention the #org.freedesktop.portal.Request::Response signal

I think the response signal should carry an id that should be passed to FinishAcquireDevices. That way there is no problem with calling AcquireDevices multiple times before calling FinishAcquireDevices.

swick · 2024-09-17T12:26:38Z

data/org.freedesktop.portal.Usb.xml

+
+        There are no supported keys in the @options vardict.
+     -->
+    <method name="ReleaseDevices">


Should probably say something about the relation to the session and connection. I assume closing the session or connection implicitly also releases all devices?

Eh, there is no session involved with acquiring and releasing devices, only a connection. The question still remains: what happens when the connection is closed. Same as release? Nothing?

when the dbus connection is closed all the devices are removed (ie released)

I think my suggestion on FinishAcquireDevices would resolve this thread.

swick · 2024-09-17T12:28:15Z

data/org.freedesktop.portal.Usb.xml

+
+        * ``action`` (``s``)
+
+          Type of event that occurred. One of "add", "change", or "remove".


What happens when one has acquired a device and it got removed? Is the fd still usable? Only sometimes?

We don't have a mechanism for revoking the fd so a real device unplug will result in a remove with the fd becoming unusable but when the user wants to revoke a device, we can't do anything with the existing fd on the client and so it won't be.

I think my suggestion on FinishAcquireDevices would resolve this thread as well.

swick · 2024-09-17T12:29:00Z

data/org.freedesktop.portal.Usb.xml

+        @devices: Array of device identifiers
+        @options: Vardict with optional further information
+
+        Releases previously acquired devices.


What does it mean to release a device? Is the fd still usable?

It will close the file descriptor when we release the "owned device" object. I haven't checked how libusb, for example, reacts to this.

Well, it closes the fd on the portal side which is good because we need to do that to not leak things, but it doesn't close the fd on the client side. In fact, you cannot close the fd on the client side from the portal side. The only thing we can do is revoke file descriptors but that currently only works for evdev and hidraw and not for usb. So as long as we don't get kernel support for that, clients will be able to continue to use the fd that they acquired even if the connection is closed. We should however say something in the interface description here which will allow us to revoke those USB devices if the connection gets closed, or if the user wants to revoke access manually, when we get USB revoke from the kernel.

swick

Looked through the usb.c file now. Mostly nickpicks but also a few actual issues we have to work out.

src/usb.c

swick · 2024-09-18T14:15:43Z

src/usb.c

+      g_dbus_method_invocation_return_error (invocation,
+                                             XDG_DESKTOP_PORTAL_ERROR,
+                                             XDG_DESKTOP_PORTAL_ERROR_FAILED,
+                                             "Cannot call AcquireDevices() with an unfinished "


Why not? The interface description doesn't mention this restriction at all.

The changes I proposed on AcquireDevices would resolve this thread.

this is done in the current code.

src/usb.c

swick · 2024-09-18T14:25:15Z

data/org.freedesktop.portal.Usb.xml

+        This method can only be called once, and only after calling
+        org.freedesktop.portal.Usb.AcquireDevices().


I think the response signal should carry an id that should be passed to FinishAcquireDevices. That way there is no problem with calling AcquireDevices multiple times before calling FinishAcquireDevices.

swick · 2024-09-18T14:35:32Z

src/usb.c

+      owned_device = g_hash_table_lookup (sender_info->owned_devices, access_data->device_id);
+      if (!owned_device)
+        {
+          fd = open (device_file, access_data->writable ? O_RDWR : O_RDONLY);


Why would opening the file fail? Is udev already telling us that we should be able to open the device node (i.e. we have permission to do it) or is do we discover about bad permissions just here?

many reason. It's IO nothing is guaranteed. The device could have disappear, could be unitialized. If it can go wrong it will go wrong.

Right, but that means we'll show USB devices to the portal clients, letting users go through the UI to approve access, just to then eventually notice that we actually can't make the device available. Would be much nicer if we didn't advertise those devices in the first place.

there is not a lot we can do. We can call access on the device is_gudev_device_suitable() and return FALSE if the call fail. That will check for existance and read permission. At that leve we don't know if we want the write permissions.

And we already check in handle_acquire_devices() as well.

Still a lot of race condition can occur it acquiring the device.

we no longer do. the change just hadn't been pushed yet.

Maybe I'm blind but I can't seem to find it? Are you sure you pushed the latest version now?

https://github.com/flatpak/xdg-desktop-portal/pull/1354/files#diff-4ce7d34e66e5ca9b52f8e5666f0d4efe11e48278f34a7cdba6df390c14012a27R163

Which mean if it can't access it it won't list it. So open won't be attempted. In case of race condition, ie the device is no longer accessible between the list and this, then this will error normally.

Ah, I missed that one. Perfect!

actually it caused a serious regression as it didn't detect removals, and a few other things.

src/usb.c

hfiguiere · 2024-09-21T01:05:30Z

(I haven't addressed everything yet)

hfiguiere · 2024-11-17T19:04:58Z

The test passes as I work around skipping in CI the one that fails.

data/org.freedesktop.portal.Usb.xml

src/xdp-app-info-flatpak.c

src/usb.c

src/xdp-usb-query.h

swick

There are a bunch of commits which fix up previous commits. I would prefer them to be squashed down.

src/usb.c

tests/__init__.py

.github/workflows/container.yml

hfiguiere · 2024-12-03T20:07:57Z

There are a bunch of commits which fix up previous commits. I would prefer them to be squashed down.

I will squash all the USB portal stuff into one and keep the test commits as they are.

Also I will shorten the commit message but copy that content into a separate file in doc that will be added to the commit. It makes more sense to have it there.

swick · 2024-12-03T22:48:29Z

LGTM

swick

Just some nit picking about the commits...

src/xdp-request.c

src/xdp-utils.c

src/xdp-usb-query.c

Signed-off-by: Hubert Figuière <hub@figuiere.net>

Implement XdpUsbQuery Co-Authored By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com> Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com> Signed-off-by: Hubert Figuière <hub@figuiere.net>

Add a new D-Bus interface org.freedesktop.portal.Usb See doc/usb-portal.md Co-Authored By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com> Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com> Signed-off-by: Hubert Figuière <hub@figuiere.net>

We want to test the USB portal which requires USB queries to determine which USB devices should be enumerable and could potentially be acquired. This adds an environment variable similar to the one for the app id that the test harness can set.

This lets us control which USB devices are enumerable by setting the fixture to valid xdp USB query.

This is because it fails as we never get the removal event. In both podman and docker Signed-off-by: Hubert Figuière <hub@figuiere.net>

CarlSchwan · 2024-12-06T08:58:17Z

data/org.freedesktop.impl.portal.Usb.xml

+      org.freedesktop.impl.portal.Usb:
+      @short_description: USB portal backend interface
+
+      This portal lets applications register global shortcuts so they can


The description seems wrong, this has afaik nothing to do with global shortcut

Indeed.

It also re-introduced annotations for a{sv} arguments and doesn't have annotations for the more complex types (a(sa{sv}a{sv})). Mind fixing that up?

oops. I missed that too. Will address this.

not sure about the annotation. Will followup too.

added the annotations to the same PR.

hfiguiere force-pushed the usb-portal branch 2 times, most recently from cb66d92 to f28ffdf Compare May 6, 2024 02:29

hfiguiere force-pushed the usb-portal branch 3 times, most recently from ce2b214 to 4907506 Compare May 20, 2024 00:51

hfiguiere force-pushed the usb-portal branch from bf64980 to 393f863 Compare June 22, 2024 01:43

hfiguiere force-pushed the usb-portal branch from 393f863 to 74f9508 Compare August 15, 2024 02:33

hfiguiere self-assigned this Sep 5, 2024

hfiguiere force-pushed the usb-portal branch from 74f9508 to 761f0a9 Compare September 14, 2024 03:05

hfiguiere marked this pull request as ready for review September 14, 2024 03:05

hfiguiere force-pushed the usb-portal branch 2 times, most recently from 69843ce to 4dcfc94 Compare September 14, 2024 18:35

swick reviewed Sep 17, 2024

View reviewed changes

swick reviewed Sep 18, 2024

View reviewed changes

hfiguiere force-pushed the usb-portal branch 2 times, most recently from a258338 to b40ccee Compare September 21, 2024 00:12

hfiguiere force-pushed the usb-portal branch 7 times, most recently from bdaa78e to 27f10e2 Compare September 26, 2024 03:40

hfiguiere force-pushed the usb-portal branch 3 times, most recently from a8ce8e9 to a3123a1 Compare October 9, 2024 01:47

hfiguiere force-pushed the usb-portal branch 2 times, most recently from bc4aced to d2e1553 Compare November 17, 2024 18:56

GeorgesStavracas requested changes Dec 2, 2024

View reviewed changes

data/org.freedesktop.portal.Usb.xml Outdated Show resolved Hide resolved

src/xdp-app-info-flatpak.c Outdated Show resolved Hide resolved

src/usb.c Outdated Show resolved Hide resolved

src/xdp-usb-query.h Outdated Show resolved Hide resolved

hfiguiere force-pushed the usb-portal branch 3 times, most recently from 14e2e57 to 70f9647 Compare December 3, 2024 03:05

swick reviewed Dec 3, 2024

View reviewed changes

src/usb.c Outdated Show resolved Hide resolved

tests/__init__.py Show resolved Hide resolved

.github/workflows/container.yml Outdated Show resolved Hide resolved

hfiguiere force-pushed the usb-portal branch from 70f9647 to 9d5ee72 Compare December 3, 2024 21:15

hfiguiere force-pushed the usb-portal branch from 9d5ee72 to 03bea78 Compare December 3, 2024 22:59

swick reviewed Dec 3, 2024

View reviewed changes

src/xdp-request.c Show resolved Hide resolved

src/xdp-utils.c Show resolved Hide resolved

src/xdp-usb-query.c Show resolved Hide resolved

hfiguiere force-pushed the usb-portal branch from 03bea78 to a396a0c Compare December 3, 2024 23:45

hfiguiere and others added 8 commits December 4, 2024 20:19

xdp-utils: Fix a const for xdp_filter_options

df73456

Signed-off-by: Hubert Figuière <hub@figuiere.net>

xdp-request: add xdp_request_get_object_path

25aa2db

Signed-off-by: Hubert Figuière <hub@figuiere.net>

xdp-app-info: get the USB queries

ba31237

Implement XdpUsbQuery Co-Authored By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com> Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com> Signed-off-by: Hubert Figuière <hub@figuiere.net>

Introduce USB portal

a37e04c

Add a new D-Bus interface org.freedesktop.portal.Usb See doc/usb-portal.md Co-Authored By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com> Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com> Signed-off-by: Hubert Figuière <hub@figuiere.net>

tests/py: Allow setting usb_queries for AppInfoTest via fixture

88752e8

This lets us control which USB devices are enumerable by setting the fixture to valid xdp USB query.

tests/usb: Test the USB portal via pytest, dbusmock and umockdev

a002ee8

test: Disable USB removal test in a container

f715778

This is because it fails as we never get the removal event. In both podman and docker Signed-off-by: Hubert Figuière <hub@figuiere.net>

hfiguiere force-pushed the usb-portal branch from a396a0c to f715778 Compare December 5, 2024 01:35

GeorgesStavracas approved these changes Dec 5, 2024

View reviewed changes

GeorgesStavracas merged commit 06a5e50 into flatpak:main Dec 5, 2024
5 checks passed

GeorgesStavracas added this to the 1.20 milestone Dec 5, 2024

hfiguiere deleted the usb-portal branch December 5, 2024 13:50

hfiguiere mentioned this pull request Dec 5, 2024

Add USB device access portal #227

Closed

danirabbit mentioned this pull request Dec 5, 2024

Implement USB Portal elementary/portals#123

Open

CarlSchwan reviewed Dec 6, 2024

View reviewed changes


		* ``properties`` (``a{sv}``)

		A list of udev properties that this device has. These properties

		This method can only be called once, and only after calling
		org.freedesktop.portal.Usb.AcquireDevices().


		* ``action`` (``s``)

		Type of event that occurred. One of "add", "change", or "remove".

USB portal (cont.) #1354

USB portal (cont.) #1354

Conversation

hfiguiere commented Apr 30, 2024 • edited Loading

hfiguiere commented Aug 15, 2024

hfiguiere commented Sep 14, 2024

swick left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swick left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swick left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hfiguiere commented Sep 21, 2024

hfiguiere commented Nov 17, 2024

swick left a comment

Choose a reason for hiding this comment

hfiguiere commented Dec 3, 2024

swick commented Dec 3, 2024

swick left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hfiguiere commented Apr 30, 2024 •

edited

Loading

swick left a comment •

edited

Loading