Auto-connect personal-files request for Krita

Krita stores asset bundles in ~/.local/share/krita/. It’s common for users to manually add additional asset bundles there. Krita also has a built-in “resource manager” which is also used to modify, add and remove assets in that folder. However, many users still do it manually and most documentation explains the manual way.

I’d like to request auto-connection for read and write permissions to that folder. I’m assuming this is the correct syntax?

  dot-local-share-krita:
    interface: personal-files
    write:
      - $HOME/.local/share/krita/`

I guess krita-snap therefore uses :

~/snap/krita/snap_number_version/.local/share

Remind snap never get access to / and hidden files for safety.
So user’s config are not stored in legacy paths but in ~/snap/app

This is the current behavior, yes. I’d like to change it back to the legacy path in order to better support the current users’ workflow, the existing documentation and existing advice that’s out there.

It won’t happen.

This is how it works for any snap.

The personal-files interface is for very specific use-case as it implies security concerns.

You may then ask the same applied to Gimp, for plugins, brushes and the likes. Or Firefox or Chromium for easy transfer of profiles… But these would break the whole « confinement » thing.

I have not found a defined list of requirements for personal-files. Neither in auto-connection requests nor in permissive interfaces @jdstrand are the requirements for personal-files defined somewhere else?

When I look at previous auto-connection requests, however, it seems like an application is easily granted personal-files access if those files are clearly owned by the application.

Note that chromium actually has an auto-connected personal-files plug for easy transfer of profiles:

  chromium-config:
    interface: personal-files
    read:
    - $HOME/.config/chromium
    - $HOME/.chromium-browser.init

This makes sense to me: the goal of confinement is that the application does not have access to other parts of the system. If an application only has access to personal files which are clearly owned by that application, then there is no confinement issue.

If you had a previous installation of krita as a .deb which stored things in~/.local/share/krita then the personal-files interface would copy those into the matching directory in ~/snap/krita/…

In no case personal-files will let you use ~/.local/share… afterwards ( post snap install ) to config’ your snap.
To do so, you have to use ~/snap/krita/…

That is not true…

if you have a convincing reason why you need write access to the former file, it will be granted (now dont ask what these convincing reasons are … but we are usually not blunty saying “no”, which is (i guess) why @galgalesh filed this request :wink: )

1 Like

What is not true ?

Ok, a write access may be granted through personal-files but if you start doing so for krita and ~/.local/share/… then you’ll have to provide this for any snap as some people might like to use good-old-legacy paths to tinker-tweak their favourite app’s…

So I’ll ask that for gimp and ~/.cache/thumbnails to fix this → GiMP and thumbnails for .xcf files → but you’ve already answered and it sounded like a no.

if i.e. other apps would heavily depend on whatever your app has in ~/.local, your app is the only provider and clear owner, oher apps crash if the files in ~/local/share/app are outdated etc, i could imagine write access to be gratnted … note though that i’m not a reviewer though …

the review processes we have are exactly to cover such corner cases, else auto-connect and permissions for such specific interfaces could just be grated blindly or we could simply remvoe the interfaces :wink:

Mmm… so should I create another post for requesting gimp write access to ~/.cache/thumbnails ?

@galgalesh - the personal-files interface is typically used to provide read-only access to top-level hidden data directories within a user’s real home directory in order to support importing data from existing applications where the snap is the clear owner of the target directory. Krita is the clear owner of ~/.local/share/krita/, so read access would easily be granted.

For write access, is krita’s resource manager forwards and backwards compatible such that on a system with krita from traditional packaging and krita as a snap are both installed, but with different versions, can the snap break the system’s krita or vice versa?

1 Like

I discussed this with the Krita devs and this will not break anything. The developers themselves use multiple versions of the AppImage and Flatpak at the same time and they all use ~/.local/share/krita/ for resources without any issues. Krita just ignores any resource it does not understand.

The Krita developers already support running multiple versions of Krita at the same time, so the snap will not introduce any new or unknown behavior.

One issue came up about a possible future version of Krita, although this is still subject to change. They are currently rewriting the resource manager and the current design includes some changes which require a one-way migration. In the current plans, the new version of Krita will do this migration when it starts. After this migration, older Krita versions will still work but some specific types of resources will not be accessible anymore because their subdirectory changed during the migration. Edit: the Krita developers made it clear that they want to fix these issues before it’s released, and running multiple versions of this resource manager will be possible.

I also want to point out that special care was taken in the resource manager to make sure users don’t accidentally lose resources, even if Krita itself contains a bug. For example, when resources are deleted, they are not actually removed from the filesystem, they are simply marked as “deleted” by Krita, but users can still recover them manually from the filesystem.

See the conversation on the Krita forum for more info.

Thanks for the additional information. For consistency with other snaps, can you adjust the interface reference from ‘krita-config’ to ‘dot-local-share-krita’?

+1 for use of and auto-connection for personal-files to ~/.local/share/krita with the interface reference of dot-local-share-krita.

@reviewers - can others please vote?

1 Like

I updated the request. Krita currently doesn’t include the plug yet but I’ll add the plug with the new name once auto-connection is granted.

+1 from me as well for use and auto-connection of personal-files to ~/.local/share/krita.

+1 from me too for use of and auto-connection of personal-files instance dot-local-share-krita for write access to $HOME/.local/share/krita/ as krita is the clear owner of this path and is able to handle any possible version mismatches within.

+3 votes for, 0 votes against. This is now live.

1 Like