Storing USer CFG Files

snapcraft
1

Hi there,

I think I fundamentally misunderstand something about storing user data (or cfg files) with $SNAP_USER_DATA .
If the non-snapped version uses say ~/.config/app/cfg-file, what is the proper way to say take advantage of $SNAP_USER_DATA/.config/app/cfg-file in the snapped version? Do you need to write logic into the app itself?

Or is there a better way to deal with this type of thing?

2

You can try overriding $HOME in the environment prior to launch, such as through an environment: block in your snapcraft.yaml:

apps:
  my-app:
    command: bin/my-app
    environment:
      HOME: $SNAP_USER_DATA

Though this has the drawback in redirecting the user’s expected HOME location in file browsers for non-config files.

3

There is also $XDG_CONFIG_HOME which can be set similarly to either $SNAP_USER_DATA to dump the config in ~/snap/example/current/ or $SNAP_USER_DATA/.config to indicate a standard .config folder treating $SNAP_USER_DATA as the equivalent to $HOME without actually setting it as such.

4

Thanks for the ideas!

This scenario seems like it would be a very common one. I wonder if this is something that could/should be standardized. The other thought I had was using personal-files to mark the standard config location as read/write. The idea there would be to allow people to keep config if they say upgrade to a snap version. :thinking::thought_balloon:

1 Like
5

That’s a good idea. I keep forgetting about the personal-files interface because I’ve not used it myself yet.

2 Likes
6

I keep forgetting too. I have not seen a sample yet, and the one I found does not seem to work. But I also need to go back to it (side tracked).

7

Typically you will use some intermediary that will handle that for you. Note that snapd internally remaps the value of the $HOME environment variable to exactly $SNAP_USER_DATA so that apps don’t have to do anything special.

8

Thank you for the clarification. I will look into that with my test snap package (investigating).

1 Like
9

@zyga-snapd @pedronis we talked about enabling using e.g. XDG_CONFIG_HOME via personal-files at the sprint, did the conclusion and actions from that get captured anywhere?

IIRC it was (a) enable using things like XDG_CONFIG_HOME in personal-files, but (b) require some configuration for it to work if it’s set to something non-default. But my memory is rather bad.

10

It was a side conversation that was not captured, we need to get back to @jdstrand about the details of what would need to be done for it. He was in that discussion.

11

The gist of this is that we could expose various XDG directories in different places in snapd, be they xdg base dirs (things like XDG_CONFIG_HOME) or xdg user dirs (things like XDG_DOWNLOAD_DIR). The basic idea for this is that we would support these via the use of AppArmor tunables that snapd would manage the tunables in some way (eg, either through detection or core/snapd snap config and then updating /etc/apparmor.d/tunables/… accordingly).

There are various ways of doing this implementation-wise that we could discuss. Eg, if we want snapd to be responsible for managing its own xdg base and user dirs tunables, then we could (untested):

  1. create /var/lib/snapd/apparmor/tunables
  2. add to the top of the default template: #include /var/lib/snapd/apparmor/tunables/
  3. create /var/lib/snapd/apparmor/tunables/xdg which contains various apparmor variables, eg, @{SNAP_XDG_CONFIG_HOME}=@{HOME}/.config/
  4. adjust our template and interface policy to appropriately use @{SNAP_XDG_CONFIG_HOME}
  5. allow snapd to drop files in /var/lib/snapd/apparmor/tunables/ that expand on the variables by containing things like @{SNAP_XDG_CONFIG_HOME}+=@{HOME}/.some-other-config

It is tempting to try to auto-detect these things with userd/similar and bubble that up to snapd, but I strongly warn against that because apparmor currently only supports system policy and users are not allowed to update system policy, so we don’t want something that is user-controlled that is able to influence system policy. Auto-detecting based on something that requires admin access to modify would be fine to pursue. A nice first step might be simply to add some core/snapd set config options and see how that goes.

In terms of xdg user dirs, we could employ a similar approach for translated directories (in fact apparmor proper already has the infrastructure in place in /etc/apparmor.d/tunables/xdg-user-dirs*, but the defined variables aren’t widely used (in snapd and elsewhere)). If we start carving up the home interface or want to support things like $XDG_DOWNLOAD_DIR in personal-files, we could explore this.