Flatpak default permissions

General Discussion
1

When I took the reigns of maintaining the Flatpak, I did some work to get it in line with the general principles of the format and work like a Flatpak is supposed to. This meant fixing a bunch of things so that it ran correctly and equivalently to the other Linux formats, but it also meant reducing the number of special permissions that Avogadro demanded. The only extra permission that Avogadro now requires by default is network access for plugin downloads, fragment imports etc..

One key consequence of this is that Avogadro, when run as a Flatpak, doesn’t see the vast majority of the user’s files, only a small corner specifically allocated to it (under ~/.var/app). Opening and closing files works completely fine and normally, because that goes via the file dialog and the underlying desktop portal that sees the normal filesystem and then gives Avogadro access to the files selected by the user.

In other contexts, however, paths of files in the user’s files then appear to Avogadro to simply not exist. This has led to a couple of bug reports in the past few days that aren’t really bugs (2166 and 2167). The first is specification of a Python interpreter that is in a location not visible to Avogadro, the second is that drag-and-drop of files into the program’s main window doesn’t work.

For the record, and for any future readers: the user can actually really easily fix this, all they have to do is give the Flatpak permission to access the required parts of the filesystem. On KDE Plasma this can even be done in the system settings; with GNOME/Cinnamon/other DEs it can be done with the very nice Flatseal app (available itself as a Flatpak) or of course via the flatpak CLI. At minimum, I’ll add a note to two.avogadro.cc/install/flatpak to try and help make users aware.

The question I have is whether we should simply change the default permissions that Avogadro requests to include (ideally read-only) access to the user’s home directory.

This would have the advantage that these few things would then work out-of-the-box. It’s just a bit less in the spirit of Flatpak have that broader access by default.

Either way, the user still has control. If we keep it as is, any user can give Avogadro extra permissions at any time; if we request home access by default, a user who cares is still able to unilaterally disable that access at any time via the same mechanism.

Apps should definitely be conservative in their permission demands, but the mechanism to request them exists because some apps need them to function. I’d like to know if we think that a smooth user experience that doesn’t require troubleshooting for common Avogadro workflows outweighs the arguments for strong sandboxing by default? I assume the answer is yes, but opinions welcome…

What do we think?

2

Just as a note re drag-and-drop, primarily for @ghutchis:

Drag-and-drop should actually work seamlessly for Flatpaks just like file dialogs do – there’s an XDG desktop portal that specifically enables it (the FileTransfer portal). I think it requires handling the received data in a specific way (that includes interpretation of the MIME type) but I don’t think that’s necessarily why it doesn’t work for Avogadro, as it seems Qt hasn’t implemented the respective desktop portal yet.

KDE has been handling it by implementing the desktop portal themselves for now in KCoreAddons, so we could alternatively make us of that in order to handle it.

Interestingly, the KCoreAddons repo lists autosave as one of the functionalities it provides. It’s a cross-platform library built on top of QtCore. So maybe there would be a couple of good reasons to look at adding it as a dependency…

Point being really that it’s the drag-and-drop that bothers me, and so even if we expanded the Flatpak permissions for now, maybe there’s another way round it or it’ll be implemented in Qt and at some point we won’t need it for DnD and we can go back to the restricted access.

3

Yes, I think this is probably a good idea. I had to slightly expand the Mac entitlements because Qt6 uses a different regex library that includes a JIT compiler.

It’s always important to have good sandboxing - but we want common workflows to “just work.”

As far as the KCoreAddons - the autosave has mostly been left as a “good first issue” since it wouldn’t take me long to add it. I’m somewhat surprised by the file transfer issue, but we can look into that as well if it doesn’t get added to Qt 6.x at some point.

1 Like