[Epic] Stop requiring device=all in Flatkpak permissions
Categories
(Firefox Build System :: General, enhancement)
Tracking
(Not tracked)
People
(Reporter: rmader, Assigned: rmader)
References
(Blocks 1 open bug)
Details
device=dri
will still be needed for accelerated rendering, but once we access cameras via Pipewire (bug 1724900), we should be mostly ready to drop the all
access.
What remains to be checked is if we need it for other stuff like controllers, YubiKeys etc.
Comment 1•3 years ago
|
||
Without device=all
, yubikeys don't work on the test site: https://demo.yubico.com/webauthn-technical/registration
(Tested with a YubiKey 5C NFC)
Assignee | ||
Comment 2•3 years ago
•
|
||
(In reply to Hugo Osvaldo Barrera from comment #1)
Without
device=all
, yubikeys don't work on the test site: https://demo.yubico.com/webauthn-technical/registration(Tested with a YubiKey 5C NFC)
Thanks for the info!
So we need something like https://github.com/flatpak/xdg-desktop-portal/pull/559 / https://github.com/flatpak/xdg-desktop-portal/issues/227
P.S.: opened https://github.com/flatpak/flatpak/issues/4405
Comment 3•3 years ago
|
||
u2f keys are accessed through /dev/hidraw* not /dev/usb so you would need https://github.com/flatpak/xdg-desktop-portal/issues/611
Generally getting rid of device=all from ff flatpak requires so many changes on flatpak/portals side plus additional time for users to get them updated which in results makes it matter of several years ahead.
Assignee | ||
Comment 4•3 years ago
|
||
(In reply to Emerson Bernier from comment #3)
u2f keys are accessed through /dev/hidraw* not /dev/usb so you would need https://github.com/flatpak/xdg-desktop-portal/issues/611
Thanks, that's good to know. There's also https://github.com/flatpak/flatpak/issues/2764 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/110 which could solve the issue.
Generally getting rid of device=all from ff flatpak requires so many changes on flatpak/portals side plus additional time for users to get them updated which in results makes it matter of several years ahead.
Yes, that's exactly the reason why I want to start now. But the more I get into this, the more I agree that this a more an odyssey than a quick adventure. Taking the freedom to add [Epic]
to the bug title :)
Comment 5•3 years ago
|
||
Hey all, I see that's there's work to remove the usage of --device=all, which is pretty cool and all.
Problem is, it seems "--device=dri" is disabled by default for the current version (95.0), is that intended? I believe it isn't since that permission is needed for OpenGL rendering and VAAPI.
Also, it could explain why when I take a look at VAAPI-related issues I see several Flatpak users asking if it will work for them, if it is dri access is disabled by default and they don't manually enable it via CLI or Flatseal, then they very likely won't have it working at all.
Any chance you guys can enable it on a future point release or something? I can separate it to a new issue but I thought I should ask here first.
Assignee | ||
Comment 6•3 years ago
|
||
(In reply to Mateus Rodrigues Costa from comment #5)
Problem is, it seems "--device=dri" is disabled by default for the current version (95.0), is that intended?
Hm, no, that would be neither intended nor do I see it to be the case. device=all
is still present (1, 2) (and will be for quite a while) and we don't block device=dri
- as that would, as you said, disable OpenGL/hardware acceleration altogether.
Comment 7•3 years ago
|
||
Ah, sorry then.
Up until now, when packaging flatpak stuff, I thought that --device=all was to be used for all the stuff that didn't have its own separate --device permissions, like as if it would only take all the other things that are not covered by dri, kvm and shm.
So I kinda expected it to have both "dri" and "all" thogether, instead of only --device=all. It seems this was just me misunderstanding the flatpak documentation, sorry!
Comment hidden (off-topic) |
Comment 9•2 years ago
|
||
Sorry, there was a problem with the detection of inactive users. I'm reverting the change.
Description
•