flatpak
flatpak copied to clipboard
flatpak
flatpak-run: Mount /dev/bus/usb with --device=usb
This adds a new usb device in the list to grant access to the whole
USB bus. This is narrower than all and should be enough for
anything accessing the USB directly (i.e. using libusb or equivalent).
This doesn't grant access to synthesized devices, i.e those exposed in /dev but using USB, including but not limited to USBserial, webcams, hidraw, hid, sound.
Close #4405
-- END COMMIT MESSAGE This is part of the ongoing work in #5620.
With --device=usb the whole USB bus is exposed without having to use --device=all.
This has the same problem from #5681 with PR #5708 as a proposal.
With the USB device portal from #5620, the plan is to have the disable if the use of the portal is requested. The idea is to compromise between the work required to use the USB portal (it's not zero cost) and the use of --device=all..
LGTM with the obvious caveats of not having a fallback just like --device=input.
Is this permission actually useful considering https://github.com/flatpak/flatpak/issues/4405#issuecomment-916716062 ?
It's a fair point. Do we have any apps that could switch from --device=all to --device=usb?
Is this permission actually useful considering #4405 (comment) ?
--device=usb is for raw USB access (with libusb, for example) not for synthesized devices on top of USB. /dev/input is already added with --device=input. (don't know for hidraw) Audio devices (includng MIDI) are already present with --socket=pulseaudio, etc. USB camera are handled with video devices which we don't have support for yet, but there have been requests for "webcams"
There are plenty of use case for raw USB: everything that use libusb, libgphoto2, SANE. The OP for the issue wants it for FIDO keys. Etc.
As for usbmon I think we can skip this one for now.
The whole think remain pointless without fallback mechanism anyway. As is the USB portal work.
There are plenty of use case for raw USB: everything that use libusb, libgphoto2, SANE. The OP for the issue wants it for FIDO keys. Etc.
FIDO is hidraw or bt.
Are there any apps on flathub which could use the new permission? All of that is information that should be in the commit message as well.
The list is too long. Look for packages that install libgphoto2, SANE, among other things - chances is that they are the ones. @GeorgesStavracas boatswain (even though he prefers the portals that is one more level in the stack - a differnt PR).
hidraw could be another permission then.
This is not meant to solve it all. This is also meant be less broad than all but not as narrow as what some people want - while still working out of the box. [1]
[1] fallback excepted.
For Boatswain, I'll be happy to switch to --device=usb in the absence of a portal. (I'd still prefer no static permissions and a working portal, of course, but downgrading the permissions is already a win for me.)
@GeorgesStavracas Did you confirmed it works correctly with just /dev/bus/usb exposed?
$ ./_build/app/flatpak run --nodevice=all --device=dri --device=usb net.epson.epsonscan2
$ flatpak enter 2048252266 sh
sh-5.2$ ls -l /dev/
total 0
drwx------. 3 hub hub 60 Jun 26 13:41 bus
crw--w----. 1 hub nfsnobody 136, 16 Jun 26 13:41 console
lrwxrwxrwx. 1 hub hub 11 Jun 26 13:41 core -> /proc/kcore
drwxr-xr-x. 3 nfsnobody nfsnobody 100 Jun 18 17:12 dri
lrwxrwxrwx. 1 hub hub 13 Jun 26 13:41 fd -> /proc/self/fd
crw-rw-rw-. 1 nfsnobody nfsnobody 1, 7 Jun 18 17:12 full
crw-rw-rw-. 1 nfsnobody nfsnobody 1, 3 Jun 18 17:12 null
lrwxrwxrwx. 1 hub hub 8 Jun 26 13:41 ptmx -> pts/ptmx
drwxr-xr-x. 2 hub hub 0 Jun 26 13:41 pts
crw-rw-rw-. 1 nfsnobody nfsnobody 1, 8 Jun 18 17:12 random
drwxr-xr-x. 2 hub hub 40 Jun 26 13:41 shm
lrwxrwxrwx. 1 hub hub 15 Jun 26 13:41 stderr -> /proc/self/fd/2
lrwxrwxrwx. 1 hub hub 15 Jun 26 13:41 stdin -> /proc/self/fd/0
lrwxrwxrwx. 1 hub hub 15 Jun 26 13:41 stdout -> /proc/self/fd/1
crw-rw-rw-. 1 nfsnobody nfsnobody 5, 0 Jun 26 14:00 tty
crw-rw-rw-. 1 nfsnobody nfsnobody 1, 9 Jun 18 17:12 urandom
crw-rw-rw-. 1 nfsnobody nfsnobody 1, 5 Jun 18 17:12 zero
sh-5.2$
And I'm scanning stuff right now.
- it's the right version of flatpak otherwise it would error.
- it definitely doesn't expose all otherwise there would be much more nodes in /dev
- it definitely expose USB as the /dev/bus entry is listed
- scanner just work as usual.
And:
- This is on a different system than I develop this, so the build is fresh from the branch if this PR, no other hacks.
@GeorgesStavracas Did you confirmed it works correctly with just
/dev/bus/usbexposed?
I did not test this branch, no.
Once there is a fallback mechanism, Epson scan would be one of the first I update to restrict. Implementing the portals for it will be more delicate if possible at all.
I haven't been able to test a pure SANE scanner app.
@smcv tentatively requested your review here. If you do not wish to review this PR, feel free to unassign yourself from the reviewers list
hidraw could be another permission then
As I'm sure was discussed at length before, a static sandboxing parameter for raw HID is technically problematic to implement, because the /dev/hidrawX devices aren't nicely grouped into a subdirectory, and are expected to be created and destroyed during runtime when HID devices (particularly game controllers) are connected and disconnected.
The only thing we could do that would be an improvement on --device=all for raw HID would be to bind-mount the devices that happen to already exist during startup, but then users will complain that hotplugging doesn't work: newly-plugged game controllers won't appear, and unplugged game controllers won't disappear.
So --device=input and --device=usb are probably the only device classes we can usefully enable, apart from /dev/snd (which at the moment is treated as part of --socket=pulseaudio, because the user-facing purpose of that permission is something like "unrestricted audio recording and playback" and the precise implementation isn't really relevant).
In principle the same problem exists for --device=dri, but hot-plugging GPUs is much, much less common than hot-plugging HID devices, so the limitation of having hotplug not work is a lot less of a problem for dri.
We handle USB here because of the upcoming USB portal and it's fairly simple in comparison. I don't know how we can handle dynamic device node tree. Maybe through a FUSE filesystem? But this is a question for another time.