Allow exposing optical media devices #12

alexlarsson · 2016-05-19T15:30:42Z

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

alexlarsson · 2016-05-19T15:30:43Z

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?

alexlarsson · 2016-05-19T15:30:44Z

From @hadess on April 22, 2016 11:47

Right now? systemd-udev has rules to mark "CD drives" (meaning any optical media) as such:
/usr/lib/udev/rules.d/50-udev-default.rules
and
/usr/lib/udev/rules.d/60-cdrom_id.rules

I don't know what changes the permissions to access it though.

magcius · 2016-06-13T22:10:09Z

Read-only media doesn't seem too dangerous... is it?

alexlarsson · 2016-06-14T02:56:01Z

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.

magcius · 2016-06-14T03:53:47Z

Hm, I thought there was /dev/cdrom and such. Could we link in /dev/by-id/etc. and ask people to just use udev?

hadess · 2016-06-14T08:23:25Z

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.

hadess · 2016-06-14T08:32:41Z

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)

alexlarsson · 2016-06-14T19:44:56Z

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.

matthiasclasen · 2016-06-14T22:36:20Z

See a84f725

alexlarsson · 2016-06-15T04:04:30Z

@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?

hadess · 2016-06-15T09:48:43Z

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.

alexlarsson · 2016-07-01T11:10:12Z

For now, --device=all which gives full access to the host /dev.

victorlevasseur · 2016-07-04T09:40:16Z

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 ?

hadess · 2016-07-04T09:51:43Z

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.

victorlevasseur · 2016-07-04T09:54:50Z

Ok, thanks for your answer. I was just asking because SFML depends on the udev libraries :(

hadess · 2016-07-04T10:00:42Z

SDL at least has the ability to disable the udev dependency. Does SFML not have the same option?

victorlevasseur · 2016-07-04T10:04:56Z

No, I'm currently trying to write a patch (to disable the joystick support first).

Jehan · 2017-01-29T13:12:37Z

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.

hadess · 2017-01-30T09:33:57Z

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?

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.

alexlarsson · 2017-01-30T10:36:43Z

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.

alexlarsson · 2017-01-30T10:37:47Z

It would be interesting to know if you did any research on this what exactly it ends up using it for.

hadess · 2017-01-30T10:42:04Z

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).

alexlarsson · 2017-01-30T11:22:53Z

Similar to #7 then

hadess · 2017-01-30T11:27:06Z

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"

Jehan · 2017-01-30T14:30:12Z

It would be interesting to know if you did any research on this what exactly it ends up using it for.

Yes I did investigate. We only use libgudev (i.e. libudev) in a single file (modules/gimpinputdevicestore-gudev.c), a module for input devices. It seems it would be used for special kind of devices, like midi stuff, because GIMP has such a feature to be controlled through all kind of funny devices.

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).
Do you have any knowledge of which lib can be used to get similar feature as libudev while still flatpak-friendly? There is no need for someone to work on this feature if it ends up the same in the end, and not working in a flatpak.

hadess · 2017-01-30T14:36:54Z

Do you have any knowledge of which lib can be used to get similar feature as libudev while still flatpak-friendly? There is no need for someone to work on this feature if it ends up the same in the end, and not working in a flatpak.

Not yet, this would need a portal. Help implementing it, or at least drawing the API would be appreciated.

Jehan · 2017-01-30T14:55:15Z

Not yet, this would need a portal. Help implementing it, or at least drawing the API would be appreciated.

Ok message noted. :-)
I can't promise anything though, because that's not a top priority for me either. But if I can make some time at some point, I will help.

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. :-)

alexlarsson · 2017-01-30T15:02:05Z

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

Jehan · 2018-11-21T11:14:22Z

Raising this back from the dead since by mindelessly wandering on the shared-modules repo of flathub today, I discover: https://github.com/flathub/shared-modules/tree/master/udev

Is this to say that it is now possible to build libudev in a flatpak?

hadess · 2018-11-21T12:22:00Z

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.

hadess · 2019-08-26T07:27:25Z

Updated gvfs RFE, for device enumeration:
https://gitlab.gnome.org/GNOME/gvfs/issues/281

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 <[email protected]>

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 <[email protected]>

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 <[email protected]> (cherry picked from commit ce4bb3d)

libgudev depends on libudev which doesn't work in Flatpak See • flatpak/flatpak#12 (comment) • flatpak/flatpak#7

alexlarsson mentioned this issue May 19, 2016

Allow exposing optical media devices alexlarsson/xdg-app#139

Closed

alexlarsson added the enhancement label Aug 29, 2016

Hjdskes mentioned this issue May 16, 2017

Create a Flatpak including libratbag and ratbagd libratbag/piper#5

Closed

9 tasks

TingPing mentioned this issue Nov 20, 2017

Playing a CD isn’t possible with the flatpaked version celluloid-player/celluloid#331

Open

Lctrs mentioned this issue Mar 28, 2018

Add the missing libdiscid modules flathub/org.musicbrainz.Picard#8

Merged

bochecha pushed a commit to flathub/org.musicbrainz.Picard that referenced this issue Mar 28, 2018

Give Picard access to all devices

64c5b41

This is unfortunately necessary to access CDs and DVDs, until Flatpak grows something more contained: flatpak/flatpak#12

bochecha mentioned this issue Mar 28, 2018

Give Picard access to all devices flathub/org.musicbrainz.Picard#9

Merged

Jehan mentioned this issue May 6, 2018

Can't access files in /tmp flathub/org.gimp.GIMP#11

Closed

nicolasfella mentioned this issue May 9, 2019

flatpak update crashes: failed to allocate 2147483648 bytes #2885

Closed

quiescentnexus mentioned this issue Oct 10, 2019

Add flatpak support Nitrokey/nitrokey-app#114

Closed

nedrichards mentioned this issue Dec 8, 2019

Add ca.littlesvr.asunder flathub/flathub#1289

Closed

alex285 mentioned this issue Nov 22, 2021

[Bug]: Failed to get revokefs-fuse socket from system-helper: Could not activate remote peer. #4598

Closed

3 tasks

j8r mentioned this issue Jan 9, 2023

Could not find any CD/DVD-ROM devices. Please ensure you have a drive connected and sufficient permissions to access it. flathub/net.pcsx2.PCSX2#152

Closed

gnomesysadmins pushed a commit to GNOME/gnome-build-meta that referenced this issue Jun 18, 2023

libmanette: Disable gudev

87713c0

libgudev depends on libudev which doesn't work in Flatpak See flatpak/flatpak#12 (comment) See also flatpak/flatpak#7

theofficialgman mentioned this issue Jul 4, 2023

[Feature request]: allow flatpak runtimes and apps to specify additional bind-mounts #5467

Open

2 tasks

voidpointertonull mentioned this issue Nov 7, 2023

[Feature request]: Android-like permissions #5304

Closed

2 tasks

gnomesysadmins pushed a commit to GNOME/gnome-build-meta that referenced this issue Jan 7, 2024

libmanette: Disable gudev

817de30

libgudev depends on libudev which doesn't work in Flatpak See • flatpak/flatpak#12 (comment) • flatpak/flatpak#7

gnomesysadmins pushed a commit to GNOME/gnome-build-meta that referenced this issue Feb 1, 2024

libmanette: Disable gudev

0dd4678

libgudev depends on libudev which doesn't work in Flatpak See • flatpak/flatpak#12 (comment) • flatpak/flatpak#7

gnomesysadmins pushed a commit to GNOME/gnome-build-meta that referenced this issue Feb 10, 2024

libmanette: Disable gudev

b782f05

libgudev depends on libudev which doesn't work in Flatpak See • flatpak/flatpak#12 (comment) • flatpak/flatpak#7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow exposing optical media devices #12

Allow exposing optical media devices #12

alexlarsson commented May 19, 2016

alexlarsson commented May 19, 2016

alexlarsson commented May 19, 2016

magcius commented Jun 13, 2016

alexlarsson commented Jun 14, 2016

magcius commented Jun 14, 2016

hadess commented Jun 14, 2016

hadess commented Jun 14, 2016

alexlarsson commented Jun 14, 2016

matthiasclasen commented Jun 14, 2016

alexlarsson commented Jun 15, 2016

hadess commented Jun 15, 2016

alexlarsson commented Jul 1, 2016

victorlevasseur commented Jul 4, 2016

hadess commented Jul 4, 2016

victorlevasseur commented Jul 4, 2016

hadess commented Jul 4, 2016

victorlevasseur commented Jul 4, 2016

Jehan commented Jan 29, 2017

hadess commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

hadess commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

hadess commented Jan 30, 2017

Jehan commented Jan 30, 2017

hadess commented Jan 30, 2017

Jehan commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

Jehan commented Nov 21, 2018

hadess commented Nov 21, 2018

hadess commented Aug 26, 2019

Allow exposing optical media devices #12

Allow exposing optical media devices #12

Comments

alexlarsson commented May 19, 2016

alexlarsson commented May 19, 2016

alexlarsson commented May 19, 2016

magcius commented Jun 13, 2016

alexlarsson commented Jun 14, 2016

magcius commented Jun 14, 2016

hadess commented Jun 14, 2016

hadess commented Jun 14, 2016

alexlarsson commented Jun 14, 2016

matthiasclasen commented Jun 14, 2016

alexlarsson commented Jun 15, 2016

hadess commented Jun 15, 2016

alexlarsson commented Jul 1, 2016

victorlevasseur commented Jul 4, 2016

hadess commented Jul 4, 2016

victorlevasseur commented Jul 4, 2016

hadess commented Jul 4, 2016

victorlevasseur commented Jul 4, 2016

Jehan commented Jan 29, 2017

hadess commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

hadess commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

hadess commented Jan 30, 2017

Jehan commented Jan 30, 2017

hadess commented Jan 30, 2017

Jehan commented Jan 30, 2017

alexlarsson commented Jan 30, 2017

Jehan commented Nov 21, 2018

hadess commented Nov 21, 2018

hadess commented Aug 26, 2019