-
-
Notifications
You must be signed in to change notification settings - Fork 397
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
Allow exposing optical media devices #12
Comments
I understand the need, but direct block device access is scary stuff it things go wrong. I mean, a cdrom device is just a block device node like any other, such as your ide disks... How does user permissions for dvd devices work? What makes it possible for the user to read the dvd drive device? |
From @hadess on April 22, 2016 11:47 Right now? systemd-udev has rules to mark "CD drives" (meaning any optical media) as such: I don't know what changes the permissions to access it though. |
Read-only media doesn't seem too dangerous... is it? |
I don't mean that read only access to cdrom is all that dangerous, but that exposing block devices in general is a tricky area to get right. There is nothing "special" about cdrom devices, they are just some random /dev/sd* name, and you have to do i/o on the device node to know what type it is, and this can change dynamically over time. |
Hm, I thought there was /dev/cdrom and such. Could we link in /dev/by-id/etc. and ask people to just use udev? |
The filename of the device isn't the problem. There's a problem with discovery, and hotplugging of the device, and ensuring that the device is only available to applications when specific discs are inside. Eg. playback application should be able to access the data on the disc, and poke the device (via the device node) only if there's a DVD, or VCD inside. |
I forgot the second part of the question: udev client libraries aren't in the platform because the protocol used by udev isn't considered stable. We'll need discovery methods similar to PulseAudio, pinos, and others for optical discs (though it could be implemented in gvfs, see https://bugzilla.gnome.org/show_bug.cgi?id=766914) |
We discussed this a bit at the hackfest. One option is to have a permission option to have full /dev access. This is not something that you should normally use, but it definately has its place if you're mostly using flatpak for distribution, not sandboxing. I will add this to flatpak. We also have some ideas of using fuse to allow dynamic access to some limited subset of device types. I will have a look at how doable this is. |
See a84f725 |
@hadess Does totem need to do anything but reads/seeks on the block device? I.e. does it need any ioctls or similar weird things? |
It does need a number of ioctls for DVDs to work. I don't know what would be necessary to play back VCDs or Blu-Ray, but I imagine that there are equivalent calls for those. |
For now, --device=all which gives full access to the host /dev. |
I'm trying to bundle SFML with flatpak but it can't find the udev libraries in the org.Gnome.Sdk SDK. Will the udev libs be ever included in the platform or not ? |
No, udev's API/ABI isn't stable, so udev libraries will never be available in the Sdk, as you don't want to rely on a particular version of the udev daemon in the host. That's why there are bugs opened about providing a way to discover things like optical media drives and joysticks. If you can think of specific device classes that will need to be accessed by applications, please file a separate bug. |
Ok, thanks for your answer. I was just asking because SFML depends on the udev libraries :( |
SDL at least has the ability to disable the udev dependency. Does SFML not have the same option? |
No, I'm currently trying to write a patch (to disable the joystick support first). |
GIMP has an optional dependency to libgudev, which in turns obviously depends on libudev. Of course, we can just deactivate the option, but we'd like to have the official GIMP flatpak as complete as possible, obviously for best experience. What is the current proposed approach? I've tried to build libudev, which basically means build the whole systemd into flatpak! (as of now, I could not find any option in systemd configure script to only build udev) That seems overkill. I still tried, but the build failed (for a reason I have not fully investigated yet, because the configure part was OK so conditions seemed met). Anyway I thought it was worth discussing our need here too. |
None. Don't try to compile libudev, it won't work inside the sandbox. You'll need to figure out why libudev is being used, and replace each of those uses with portals. I doubt that GIMP is using libudev to manage its own storage media, so this isn't the right issue to discuss this. |
Also, libudev is not accidentally left out of the runtime, I asked upstream about the stability guarantees, and it turns out that udevd (which writes the files libudev reads) does not guarantee in-file backwards compat, only libudev ABI. This means we can't put a libudev in the sandbox as it may not match what is running on the host. Also, like @hadess said, in general udev is for hardware-stuff, drivers and whatnot. I'm not sure why gimp would need it at all. |
It would be interesting to know if you did any research on this what exactly it ends up using it for. |
Pretty sure it uses it for input devices that it accesses directly (Edit -> Preferences -> Input Devices -> Input Controllers -> Linux Input). |
Similar to #7 then |
A bit broader, but yes, that's it. Joystick could be replaced there by "too complicated/too rare an input device to be handled by the Wayland/GTK+ input APIs" |
Yes I did investigate. We only use libgudev (i.e. libudev) in a single file ( To be clear, that's something I have never used myself and this is definitely not a very commonly used feature, I think. So I've discussed with Mitch and we'll just disable this in the flatpak build. I will maybe make a bug report on our side to have this replaced by an alternative implementation (though I would not be astonished such a re-implementation never comes, especially since the workaround is just to not use flatpak). |
Not yet, this would need a portal. Help implementing it, or at least drawing the API would be appreciated. |
Ok message noted. :-) Also I would suggest to maybe write some doc on the relationship between portals and permissions. From your main developer page, the only mention to portals is in the top graphics (section "Key Concept"). That makes this all a little fuzzy. :-) |
It sounds fuzzy because it is a bit fuzzy. We're somewhat building things as we go, and thing show up, and "portal" is a generic word to mean "some service that safely lets you extend what sandboxed apps can do". |
The build has been fixed by a patch from Upstream: https://bugs.webkit.org/show_bug.cgi?id=156510 Note that WebKit takes hours to build, so if you just want to test Flatpak, you may prefer disable this module again. We now have a full-feature Flatpak build, except for libgudev, which means that special input devices probably won't work in the GIMP Flatpak. It is to be noted that Flatpak developers told me that libudev won't work inside the sandbox anyway. A portal will have to be implemented. See: flatpak/flatpak#12 (comment)
This is unfortunately necessary to access CDs and DVDs, until Flatpak grows something more contained: flatpak/flatpak#12
Raising this back from the dead since by mindelessly wandering on the Is this to say that it is now possible to build libudev in a flatpak? |
It's an old version of udev, just for the purpose of shutting up builds that require libudev. It doesn't actually work for enumerating devices, or using hotplug. |
Updated gvfs RFE, for device enumeration: |
The checksum here can leak if `flatpak_dir_remote_load_cached_summary()` returns false at least once. Spotted by asan while running gnome-software: ``` Direct leak of 2925 byte(s) in 45 object(s) allocated from: #0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af) flatpak#1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130 flatpak#2 0x7f445bc860e7 in ostree_checksum_from_bytes src/libostree/ostree-core.c:1599 flatpak#3 0x7f445bdbea82 in flatpak_dir_remote_fetch_indexed_summary /opt/gnome/source/flatpak/common/flatpak-dir.c:12563 flatpak#4 0x7f445bd9932e in flatpak_remote_state_ensure_subsummary /opt/gnome/source/flatpak/common/flatpak-dir.c:577 flatpak#5 0x7f445bdbfd42 in _flatpak_dir_get_remote_state /opt/gnome/source/flatpak/common/flatpak-dir.c:12872 flatpak#6 0x7f445bdc006c in flatpak_dir_get_remote_state_optional /opt/gnome/source/flatpak/common/flatpak-dir.c:12953 flatpak#7 0x7f445be07886 in flatpak_transaction_ensure_remote_state /opt/gnome/source/flatpak/common/flatpak-transaction.c:2057 flatpak#8 0x7f445be095c7 in flatpak_transaction_add_ref /opt/gnome/source/flatpak/common/flatpak-transaction.c:2732 flatpak#9 0x7f445be09c37 in flatpak_transaction_add_update /opt/gnome/source/flatpak/common/flatpak-transaction.c:2940 flatpak#10 0x7f445bdd202c in flatpak_installation_list_installed_refs_for_update /opt/gnome/source/flatpak/common/flatpak-installation.c:1103 flatpak#11 0x7f445bf07824 in gs_flatpak_add_updates ../../source/gnome-software/plugins/flatpak/gs-flatpak.c:2082 flatpak#12 0x7f445bf2e2b9 in gs_plugin_add_updates ../../source/gnome-software/plugins/flatpak/gs-plugin-flatpak.c:484 flatpak#13 0x7f44770533b2 in gs_plugin_loader_call_vfunc ../../source/gnome-software/lib/gs-plugin-loader.c:620 flatpak#14 0x7f447705430f in gs_plugin_loader_run_results ../../source/gnome-software/lib/gs-plugin-loader.c:748 flatpak#15 0x7f447706cb03 in gs_plugin_loader_process_thread_cb ../../source/gnome-software/lib/gs-plugin-loader.c:3110 #16 0x7f44769967ed in g_task_thread_pool_thread ../../source/glib/gio/gtask.c:1531 flatpak#17 0x7f447650e760 in g_thread_pool_thread_proxy ../../source/glib/glib/gthreadpool.c:350 flatpak#18 0x7f447650dd02 in g_thread_proxy ../../source/glib/glib/gthread.c:831 ``` Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The checksum here can leak if `flatpak_dir_remote_load_cached_summary()` returns false at least once. Spotted by asan while running gnome-software: ``` Direct leak of 2925 byte(s) in 45 object(s) allocated from: #0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af) flatpak#1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130 flatpak#2 0x7f445bc860e7 in ostree_checksum_from_bytes src/libostree/ostree-core.c:1599 flatpak#3 0x7f445bdbea82 in flatpak_dir_remote_fetch_indexed_summary /opt/gnome/source/flatpak/common/flatpak-dir.c:12563 flatpak#4 0x7f445bd9932e in flatpak_remote_state_ensure_subsummary /opt/gnome/source/flatpak/common/flatpak-dir.c:577 flatpak#5 0x7f445bdbfd42 in _flatpak_dir_get_remote_state /opt/gnome/source/flatpak/common/flatpak-dir.c:12872 flatpak#6 0x7f445bdc006c in flatpak_dir_get_remote_state_optional /opt/gnome/source/flatpak/common/flatpak-dir.c:12953 flatpak#7 0x7f445be07886 in flatpak_transaction_ensure_remote_state /opt/gnome/source/flatpak/common/flatpak-transaction.c:2057 flatpak#8 0x7f445be095c7 in flatpak_transaction_add_ref /opt/gnome/source/flatpak/common/flatpak-transaction.c:2732 flatpak#9 0x7f445be09c37 in flatpak_transaction_add_update /opt/gnome/source/flatpak/common/flatpak-transaction.c:2940 flatpak#10 0x7f445bdd202c in flatpak_installation_list_installed_refs_for_update /opt/gnome/source/flatpak/common/flatpak-installation.c:1103 flatpak#11 0x7f445bf07824 in gs_flatpak_add_updates ../../source/gnome-software/plugins/flatpak/gs-flatpak.c:2082 flatpak#12 0x7f445bf2e2b9 in gs_plugin_add_updates ../../source/gnome-software/plugins/flatpak/gs-plugin-flatpak.c:484 flatpak#13 0x7f44770533b2 in gs_plugin_loader_call_vfunc ../../source/gnome-software/lib/gs-plugin-loader.c:620 flatpak#14 0x7f447705430f in gs_plugin_loader_run_results ../../source/gnome-software/lib/gs-plugin-loader.c:748 flatpak#15 0x7f447706cb03 in gs_plugin_loader_process_thread_cb ../../source/gnome-software/lib/gs-plugin-loader.c:3110 #16 0x7f44769967ed in g_task_thread_pool_thread ../../source/glib/gio/gtask.c:1531 flatpak#17 0x7f447650e760 in g_thread_pool_thread_proxy ../../source/glib/glib/gthreadpool.c:350 flatpak#18 0x7f447650dd02 in g_thread_proxy ../../source/glib/glib/gthread.c:831 ``` Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The checksum here can leak if `flatpak_dir_remote_load_cached_summary()` returns false at least once. Spotted by asan while running gnome-software: ``` Direct leak of 2925 byte(s) in 45 object(s) allocated from: #0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af) #1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130 #2 0x7f445bc860e7 in ostree_checksum_from_bytes src/libostree/ostree-core.c:1599 #3 0x7f445bdbea82 in flatpak_dir_remote_fetch_indexed_summary /opt/gnome/source/flatpak/common/flatpak-dir.c:12563 #4 0x7f445bd9932e in flatpak_remote_state_ensure_subsummary /opt/gnome/source/flatpak/common/flatpak-dir.c:577 #5 0x7f445bdbfd42 in _flatpak_dir_get_remote_state /opt/gnome/source/flatpak/common/flatpak-dir.c:12872 #6 0x7f445bdc006c in flatpak_dir_get_remote_state_optional /opt/gnome/source/flatpak/common/flatpak-dir.c:12953 #7 0x7f445be07886 in flatpak_transaction_ensure_remote_state /opt/gnome/source/flatpak/common/flatpak-transaction.c:2057 #8 0x7f445be095c7 in flatpak_transaction_add_ref /opt/gnome/source/flatpak/common/flatpak-transaction.c:2732 #9 0x7f445be09c37 in flatpak_transaction_add_update /opt/gnome/source/flatpak/common/flatpak-transaction.c:2940 #10 0x7f445bdd202c in flatpak_installation_list_installed_refs_for_update /opt/gnome/source/flatpak/common/flatpak-installation.c:1103 #11 0x7f445bf07824 in gs_flatpak_add_updates ../../source/gnome-software/plugins/flatpak/gs-flatpak.c:2082 #12 0x7f445bf2e2b9 in gs_plugin_add_updates ../../source/gnome-software/plugins/flatpak/gs-plugin-flatpak.c:484 #13 0x7f44770533b2 in gs_plugin_loader_call_vfunc ../../source/gnome-software/lib/gs-plugin-loader.c:620 #14 0x7f447705430f in gs_plugin_loader_run_results ../../source/gnome-software/lib/gs-plugin-loader.c:748 #15 0x7f447706cb03 in gs_plugin_loader_process_thread_cb ../../source/gnome-software/lib/gs-plugin-loader.c:3110 #16 0x7f44769967ed in g_task_thread_pool_thread ../../source/glib/gio/gtask.c:1531 #17 0x7f447650e760 in g_thread_pool_thread_proxy ../../source/glib/glib/gthreadpool.c:350 #18 0x7f447650dd02 in g_thread_proxy ../../source/glib/glib/gthread.c:831 ``` Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
libgudev depends on libudev which doesn't work in Flatpak See flatpak/flatpak#12 (comment) See also flatpak/flatpak#7
The checksum here can leak if `flatpak_dir_remote_load_cached_summary()` returns false at least once. Spotted by asan while running gnome-software: ``` Direct leak of 2925 byte(s) in 45 object(s) allocated from: #0 0x7f44774ba6af in __interceptor_malloc (/lib64/libasan.so.8+0xba6af) #1 0x7f44764c941a in g_malloc ../../source/glib/glib/gmem.c:130 flatpak#2 0x7f445bc860e7 in ostree_checksum_from_bytes src/libostree/ostree-core.c:1599 flatpak#3 0x7f445bdbea82 in flatpak_dir_remote_fetch_indexed_summary /opt/gnome/source/flatpak/common/flatpak-dir.c:12563 flatpak#4 0x7f445bd9932e in flatpak_remote_state_ensure_subsummary /opt/gnome/source/flatpak/common/flatpak-dir.c:577 flatpak#5 0x7f445bdbfd42 in _flatpak_dir_get_remote_state /opt/gnome/source/flatpak/common/flatpak-dir.c:12872 flatpak#6 0x7f445bdc006c in flatpak_dir_get_remote_state_optional /opt/gnome/source/flatpak/common/flatpak-dir.c:12953 flatpak#7 0x7f445be07886 in flatpak_transaction_ensure_remote_state /opt/gnome/source/flatpak/common/flatpak-transaction.c:2057 flatpak#8 0x7f445be095c7 in flatpak_transaction_add_ref /opt/gnome/source/flatpak/common/flatpak-transaction.c:2732 flatpak#9 0x7f445be09c37 in flatpak_transaction_add_update /opt/gnome/source/flatpak/common/flatpak-transaction.c:2940 flatpak#10 0x7f445bdd202c in flatpak_installation_list_installed_refs_for_update /opt/gnome/source/flatpak/common/flatpak-installation.c:1103 flatpak#11 0x7f445bf07824 in gs_flatpak_add_updates ../../source/gnome-software/plugins/flatpak/gs-flatpak.c:2082 flatpak#12 0x7f445bf2e2b9 in gs_plugin_add_updates ../../source/gnome-software/plugins/flatpak/gs-plugin-flatpak.c:484 flatpak#13 0x7f44770533b2 in gs_plugin_loader_call_vfunc ../../source/gnome-software/lib/gs-plugin-loader.c:620 flatpak#14 0x7f447705430f in gs_plugin_loader_run_results ../../source/gnome-software/lib/gs-plugin-loader.c:748 flatpak#15 0x7f447706cb03 in gs_plugin_loader_process_thread_cb ../../source/gnome-software/lib/gs-plugin-loader.c:3110 #16 0x7f44769967ed in g_task_thread_pool_thread ../../source/glib/gio/gtask.c:1531 flatpak#17 0x7f447650e760 in g_thread_pool_thread_proxy ../../source/glib/glib/gthreadpool.c:350 flatpak#18 0x7f447650dd02 in g_thread_proxy ../../source/glib/glib/gthread.c:831 ``` Signed-off-by: Philip Withnall <pwithnall@endlessos.org> (cherry picked from commit ce4bb3d)
libgudev depends on libudev which doesn't work in Flatpak See • flatpak/flatpak#12 (comment) • flatpak/flatpak#7
libgudev depends on libudev which doesn't work in Flatpak See • flatpak/flatpak#12 (comment) • flatpak/flatpak#7
libgudev depends on libudev which doesn't work in Flatpak See • flatpak/flatpak#12 (comment) • flatpak/flatpak#7
From @hadess on April 22, 2016 10:5
For DVD and VCD playback to work in totem, the application might need access to the device itself, as well as the mount point for that filesystem (to check what is on the disc).
Copied from original issue: alexlarsson/xdg-app#139
The text was updated successfully, but these errors were encountered: