Access to specific hidden file path in users $HOME

Regarding these issues here’s a related topic: Proposal: Allow exposing the public source repository that is used to build a particular snap in the store page

A workaround is to ask the user to create a hard link from the real path to the snap path manually in a launcher:

nano-launch: It appears that you have a nanorc file in your home directory, however due to snapd's security confinement it is not accessible by the snap.
nano-launch: If you wish to use it you have to create a hardlink manually by running the `ln /home/buo-ren/.config/nano/nanorc /home/buo-ren/snap/nano/common/.config/nano/nanorc` command in a terminal.
nano-launch: To silent this warning without linking create a blank file at /home/buo-ren/snap/nano/common/.config/nano/nanorc.

Press Enter to continue:

Thanks for the great suggestion @Lin-Buo-Ren, however I need to access a hidden directory so hard links are not an option.

For directories you may use bind mounts instead of hard links, however this requires superuser privileges.

Again thanks. That works well. Now if only we could prevent deletion of the files when the snap is removed…

Hi, I also believe that Snap should provide a way to access the host XDG folders.

I know that this is mainly a requirement for desktop applications, but I believe it is a big issue that currently is not possible to switch to/from Snap without loosing all your app data (just think about apps that have profiles or saves).

Snaps can request access to the default XDG folders via the personal-files interface, and apps have access to the environment variables to determine whether the user has e.g. set $XDG_CONFIG_HOME to something different than the default. If the user points $XDG_foo to a dotfile different from the one requested via personal-files, that’s not supported. And indeed the runtime configurability implied by setting $XDG_ environment variables is the reason for things not quite being as easy as you’d expect.

Interesting, I’m not really familiar with this personal-files interface, could you please help me to fix the issue described here?

This is my current snapcraft.yaml.

@chipaca can it be something like this (I not home now and I can’t test it myself)?

    write: [ $XDG_CONFIG_HOME ]
    read:  [ $XDG_CONFIG_HOME ]

no it can’t, because $XDG_CONFIG_HOME is set by the user, per-user, at runtime.

Oh I see, but as a partial workaround can it be something like this?

    write: [ $HOME/.config/gwe ]
    read:  [ $HOME/.config/gwe ]

Can I then force the $XDG_CONFIG_HOME of my Snap to be $HOME/.config (currently it points to $HOME/snap/gwe/x1/.config/)? If yes, how?
If the folder $HOME/.config/gwe does not exist already, can it be a problem? Am I allowed to create it from my snap? Would a normal mkdir -p $HOME/.config/gwe work from inside the snap?

Yes. But why do you want this? Why not use the .config inside $SNAP_USER_DATA?

As said in #17, the use case is allowing the user to switch freely and smoothly from and to Snap.

Possible use cases are:

  1. I install GWE from Flathub, I create my custom fan profiles, I uninstall Flatpak GWE and install Snap Store GWE, I still have my profiles.
  2. I install GWE from Snap Store, I create my custom fan profiles, I uninstall GWE, I reinstall GWE, I still have my profiles (maybe this is already covered by $SNAP_USER_DATA)

And other combinations using different package managers and sources for the app.

Then imagine you made (intentionally or not) backward incompatible change in app config. Now switching between different app installation sources could make shared configs broken (snaps even make effort to keep separate config for each app version).

This also breaks sandboxing guarantee as normally app can’t access other apps configs in snap/flatpak if they’re stored in designated directory but not if you set it up like you want.

Please don’t mix host & snap & flatpak configs.

@Reynolds5 I understand your POV but I still believe that it should be possible to do it if a developer want to take the challenge of maintaining backward compatibility for his $XDG_CONFIG_HOME.

Just to clarify: I don’t want this behavior to be changed for all the apps, I just want to be able to use it if needed.

That would break my app because it relies on creating profiles and keeping them between app upgrades.

To be clear, if you put data/config files in $SNAP_DATA (or $SNAP_USER_DATA) that is per-revision and any files put there will disappear and need to be repopulated on snap upgrade. However these files do get backed up on an upgrade so if the upgrade goes awry, you can revert (or in some cases the snap will be auto-reverted) to the old revision and the files will be re-populated.
If you use $SNAP_COMMON (or $SNAP_USER_COMMON) however, these files will not be modified on snap upgrade. This also means you don’t get any backup of the files in $SNAP_COMMON.

sorry, but that’s absolutely not true. The directories are per revision, but they get get backed up / copied forward (depending on the version of snapd) on upgrade; it’ll be there.

1 Like

To be clear, I may have used the phrase “disappeared” a little heavily, what I meant is that the current revision of the snap after an upgrade will not see the same files as the previous revision did because $SNAP_DATA points to a new directory.

I was aware of the backing up feature on a revert, I was not aware of the “copied forward” feature, what version of snapd was that added to? And does the “copied forward” feature apply to automatic refreshes only?

it’s been there since before it was called snapd. And no, any refresh behaves the same way wrt the data.

2 posts were merged into an existing topic: Clj-kondo linter classic snap