Before proceeding further, we might need to clarify some things. I’m unclear about a lot of things relating to snap, and most people do not fully understand the subtleties of libgphoto2.
For the purposes of the discussion here, by ‘libgphoto2 device’ I mean ‘camera or phone’. Furthermore, when I write “PTP” you can read “PTP or MTP”, and likewise
libptp can be read as
libmtp. (MTP is a superset of PTP).
I don’t think it makes sense to talk of relationship between the usdisks2 plug and the removable-media plug and a libgphoto2 device. If there is a relationship, what is it? A libgphoto2 device is not a disk and it’s not removable media. It’s a device accessed by PTP using libgphoto2. So the usdisks2 and removable-media plugs ought to be irrelevant when it comes to accessing libgphoto2 devices. (These plugs will be relevant when it comes to access to things like camera memory cards inserted via USB, I suppose).
libgphoto2 uses the process
libptp to access devices. A libgphoto2 device can only be accessed by one process at a time, which has exclusive control over and access to the device until it relinquishes it. No other process can read it, including another libgphoto2 process.
That is why for any program on any desktop, irrespective of whether snap is running or not, gPhoto2 or Rapid Photo Downloader or any other program that uses libgphoto2 cannot access a libgphoto2 device if another process is already using it.
Under Gnome, as soon as you plug in a libgphoto2 device, Gnome immediately takes control of the libgphoto2 device using GIO/ GVFS. This cannot be changed.
Under KDE, if you browse a libgphoto2 device using a KDE program like dolphin, KDE retains control of the libgphoto2 device and as I recall does not relinquish it until the program is closed.
This is a long and complicated way of saying that if a program like gPhoto2 or Rapid Photo Downloader wants to access a libghoto2 device, Gnome and KDE must relinquish control or else gPhoto2 and Rapid Photo Downloader and every other program that use libgphoto2 will not work.
Fortunately Gnome has a mechanism to relinquish control: https://lazka.github.io/pgi-docs/#Gio-2.0/classes/Mount.html#Gio.Mount.unmount_with_operation
If I understand your statement correctly, I think you’re saying that snap confinement means that no confined program can make a valid call to
Gio.Mount.unmount_with_operation under any circumstances because of security reasons? Is that correct?
If that is correct, that breaks programs that use libgphoto2. Users have to know they need to unmount / eject the libgphoto2 device in Gnome files, which very few users know. The users simply conclude the program does not work. That is why I spent a lot of time in Rapid Photo Downloader writing code that automatically calls GIO/GVFS for it to relinquish control of libgphoto2 devices.
I’m sorry but I don’t understand what this means: be sure to use /usr/bin/xdg-open from the runtime and not from inside your snap.
I had not seen it previously, but I have now thanks.