Auto connection request for FBReader

store-requests
1

Hi,

I recently uploaded very first beta of FBReader 2.0 (https://fbreader.org/) to the beta channel. I want to request automatic connection for access to some files in $HOME. The app is written using Qt6 and we use standard locations for config, app data (an sqlite database), and cache. The description looks as below:

plugs:
  home-data:
    interface: personal-files
    write:
      - $HOME/.local/share/FBReader.ORG Limited/FBReader
      - $HOME/.config/FBReader.ORG Limited
      - $HOME/.cache/FBReader.ORG Limited/FBReader

apps:
  fbreader:
    command: bin/FBReader
    plugs:
      - desktop
      - desktop-legacy
      - network
      - network-bind
      - home
      - home-data
      - x11
    environment:
      HOME: $SNAP_REAL_HOME

So I request auto-connection for home-data. It is safe, as the app only writes in it’s own catalogues and does not request any access to third-party files.

Best Regards,

– Nikolay Pultsin, on behalf of FBReader.ORG Limited

1 Like
3

Oops. Found an issue. The app has to create the listed folders on the first start. So the permissions I requested are not enough. We can change to

plugs:
  home-data:
    interface: personal-files
    write:
      - $HOME/.local/share
      - $HOME/.config
      - $HOME/.cache

Or maybe there is a better solution?

4

I’m a snap user, not a developer, but I’m very interested in an FBReader snap :smiley:

Can you not store the config data in $HOME/snap/SNAP-NAME/REVISION/ {.local,.config,.cache}? This is normal for all non-classic snaps I’ve seen (all the snaps I use except VS Code), including Qt apps like KeePassXC and MusicBrainz Picard.

5

Thank you. Probably, yes, we can. However, there are at least two arguments contra:

  1. This means that we have to change standard Qt6 mechanism of folder selection. We also use at least Downloads directory, that should be permanent (i.e., $HOME/Downloads), of course. So the standard mechanism cannot be changed globally, we have to do some hacks to use different mechanisms in different cases. Specially for the snap version.
  2. This means that if a user installs FBReader from different locations (e.g., snap and AppImage), he/she has incompatible versions, that is quite strange. And is a pain for support/testing.

Anyway, that would be great to receive some more or less “official” review, as the original request was posted a week+ ago.

6

I don’t disagree in theory, but note that this is the case for all snap apps that use a directory for config (instead of just gsettings or something), including the snaps of Chromium and Firefox. The latter two have scripts to import settings on first run of the snap, but after that they keep separate settings. So users of snaps will likely be used to that situation from other apps.

Anyway, that would be great to receive some more or less “official” review, as the original request was posted a week+ ago.

:+1:

7

I agree. My second argument is relatively weak. But I want to point a difference between a browser and the e-book reader. The reader really has user data, a database of the books. The settings are quite small. The database could have thousands of records.

FBReader supports cloud sync for the database, but some users do not trust clouds. :slight_smile:

1 Like
8

Apologies for the delay in reviewing this request.

personal-files is intended to be used more in the vein that @elcste describes, where a snap has read permission to the config in the users real home and then imports this into the snap-specific locations and then the snap can store it’s config independently from the system-installed version.

However, if a snap is the clear owner of these directories (as it is in this case as they are namespaced to FBReader.ORG Limited) and the publisher can confirm that sharing the same config between a snap version of an application and say an AppImage of the same application is not going to cause compatibility issues between the two, then this is also a standard use of personal-files using the write permission.

Regarding creating the directories, granting access to all of say $HOME/.config is far too much permission - instead you just need the following:

plugs:
  fbreader-config:
    interface: personal-files
    write:
      - $HOME/.local/share/FBReader.ORG Limited
      - $HOME/.config/FBReader.ORG Limited
      - $HOME/.cache/FBReader.ORG Limited

And then you should have complete permission to both create these directories and any child directories required within them.

Also note I have changed the name of this to fbreader-config since it is a bit more descriptive and in-line with the conventions we try and use for naming of personal-files instances.

Assuming you can vouch that fbreader is happy to share configs between the snap and other versions without compatibility issues, then +1 from me for write permission for fbreader for this personal-files instance as I have described it above.

9

Kudos @alexmurray! The solution you suggest works fine. I just tested it locally, it creates all the dirs and runs with no problem. I updated our snapcraft.yaml to

plugs:
  fbreader-config:
    interface: personal-files
    write:
      - $HOME/.local/share/FBReader.ORG Limited
      - $HOME/.config/FBReader.ORG Limited
      - $HOME/.cache/FBReader.ORG Limited

apps:
  fbreader:
    command: bin/FBReader
    plugs:
      - desktop
      - desktop-legacy
      - network
      - network-bind
      - home
      - fbreader-config
      - x11
    environment:
      HOME: $SNAP_REAL_HOME

I also confirm that sharing configs between versions from different sources is exactly what we want to do.

Please advise, can I do something to make the request more clear to other reviewers? Maybe, update the original post?

10

Well, I just uploaded a new package. The requested access is even a bit less:

plugs:
  fbreader-config:
    interface: personal-files
    write:
    - $HOME/.local/share/FBReader.ORG Limited
    - $HOME/.config/FBReader.ORG Limited

apps:
  fbreader:
    command: bin/FBReader
    command-chain:
    - bin/envelope.sh
    plugs:
    - desktop
    - desktop-legacy
    - network
    - network-bind
    - home
    - fbreader-config
    - x11
    environment:
      HOME: $SNAP_REAL_HOME

Please, any chance to have it reviewed in the next few days?

Regards,

– Nikolay

11

Since fbreader is the clear owner of $HOME/.local/share/FBReader.ORG Limited and $HOME/.config/FBReader.ORG Limited I am +1 as well for auto-connect personal-files with write access to $HOME/.local/share/FBReader.ORG Limited and $HOME/.config/FBReader.ORG Limited using the interface reference fbreader-config. +2 votes for, 0 votes against, granting the requested auto-connections. This is now live.

1 Like