Kde-neon sets home to /run/user/1000

1

Hi.
I’m using the kde-neon extension in a snap (ksnip).
It works, but the file-chooser being used converts the home folder to /run/user/1000.
I assume this is something to do with the portal, but the snap has the home permission.

The path selected in the file-chooser is a script (that runs confined in the same snap environment).
If I set the path manually with /home/… the script runs properly, but not if it is /run/user/1000/…

Could this be a problem related to the permissions set by the portal?
Is there an option to tell the portal to allow execute permissions to the loaded files?
Or is it possible instead to tell the file-chooser to have direct access to the home folder, as is intended with the snap permission?
Thanks

1 Like
2

Can you post a link to the source code of the snap? What distro, version and desktop environment are you using?

When I run ksnip from the snap store, the “open” file chooser uses my correct home directory. It does crash when I try to make a screenshot though.

Edit: it works on X11, crashes on Wayland.

1 Like
3


I’m building and running on Ubuntu 20.04 (Gnome DE)
On wayland it cannot work atm, but that is a known difference with wayland.
Ksnip for now needs x11

4

The script file-chooser (Options -> Settings -> Script Uploader) sets the incorrect path
So if I select /home/galileo/Documents/script_test.sh it’ll be saved as /run/user/1000/doc/d6354475/script_test.sh
In Options -> Settings -> Saver the chooser will not let me select a folder, even though in the source the correct qtDialog is used.
If I set the flag to not use the native dialogs (and use instead the default qt5 ones) it works as intended.

5

Do you have an example script I could test with?

I also see the same behavior but I think this is simply how xdg-desktop-portal works. xdg-desktop-portal uses FUSE to mount /home/galileo/Documents/script_test.sh to /run/user/1000/doc/d6354475/script_test.sh so that the snap has access to it. Both files should point to the same bits on disk.

6

As for your second issue, not being able to select a folder, it seems like this support was only recently added to xdg-desktop-portal. This feature will be part of the next release. When it is released, it will take a while until all distributions update xdg-desktop-portal and until this new feature is included in Qt.

It seems like there is a semi-related bug in Qt where it incorrectly uses the portal for choosing directories, even though the portal only supports files. I think Qt should first check if the directory chooser portal is supported and, if not, use a regular directory chooser.

1 Like
7

But I get an error when running the script (permissions error, file not found, resource error)
A test script can be anything, even a bash file that echoes something…

8

How do I run the script from Ksnip?

Edit: never mind, I can just run it using snap run --shell ksnip and calling bash directly.

9

After you set the path and Options->Settings->Uploader->Type is set to Script,
you start ksnip, take a new screenshot, then File->Upload

EDIT: The fact is that if you simply run the script it works…
The problem is when running from ksnip

10

It seems the issue is that the “executable” permissions are not transferred using the portal:

$ ls -al /run/user/1000/doc/fc52dd3/test-script.sh
-rw-rw-r-- 1 merlijn merlijn 32 Jul 27 21:00 /run/user/1000/doc/fc52dd3/test-script.sh

the file itself:

$ ls -al test-script.sh 
-rwxrw-r-- 1 merlijn merlijn 32 Jul 27 21:00 test-script.sh
11

I imagined that could have been the issue…
It’s a bug(?) in the portal then, I’d imagine.
Although it’s still not clear to me why it’s using the portal, since it has home access

12

Yes, I also think this is a bug. I filed it upstream: Executable bits are not retained with FileChooser portal

I don’t have any experience with Qt, but if you know your way around their bugtracker, it might be useful to file a bug there for the FileChooser directory functionality issue. (this might actually be an issue with the Platform Theme itself, depending on what your snap is using)

At the moment, all files chosen using the portal are remounted, even if the snap has access to the file using regular interfaces. Fixing this is on the long list of things @jamesh wants to do.

1 Like
13

Ok… so for the time being I can add a condition in the source to not use the native portal if running in a snap.
I’ll look at the qt bugtracker, but I’m no expert either.
I think the fact that the portal has precedence on the home permission should be documented in the permissions list page (if it is already my bad…)

Thanks for the help!!

14

Do you see different behavior in the Flatpak? Afaik, the only issue that is snap-specific is that the fuse mount is used for files which the app already has access to.

Also, where would you like to see this documented? I was thinking of adding it to the page for XDG Desktop Portals. Did you have another page in mind?

15

This app doesn’t have a flatpak atm… but this is the first time I notice this issue, on both snap and flatpak programs.

I think that a note in the Known Limitations section of XDG desktop portals would be good.
Also a note on possible incompatibilities (or suggestions) could be left on the plugs page (https://snapcraft.io/docs/supported-interfaces)

1 Like
16

I made a quick flatpak to test it out there:
the portals have the same issue,
but if I add --filesystem=host as an access permission then it works “as intended”