The personal-files interface

personal-files provides access to the specified files in the user’s home. This interface gives privileged access to the user’s data.

Auto-connect: no
Attributes:

  • read (plug): list of files and/or directories for read-only access (eg, ‘read: [ $HOME/.file-read, $HOME/.dir-read ]
  • write (plug): list of files and/or directories for read/write access (eg, ‘write: [ $HOME/.file-write, $HOME/.dir-write ]

Specifying a directory in read and write allows access to the directory and all files under it.

Transitional: no

Requires snapd version 2.37+.

This interface is typically used to provide read-only access to top-level hidden data directories within a user’s home directory in order to support importing data from existing applications where the snap is the clear owner of the target directory.

For distribution via the Snap store, consumers of this interface require an approved snap declaration. For acceptance, you will need to make a descriptive interface reference, as used by snap connections|interfaces|connect|disconnect commands.

For example, if a foo application is being packaged as a snap and its publisher wants the snap to import an existing configuration from ~/.config/foo, the snapcraft.yaml could include the following:

name: foo
...
plugs:
  config-foo:
    interface: personal-files
    read:
    - $HOME/.config/foo

apps:
  foo:
    plugs:
    - config-foo
    ...

With the above built snap, you would then be able to use the following to enable access to personal files:

$ snap connect foo:config-foo

ⓘ This is a snap interface. See Interface management and Supported interfaces for further details on how interfaces are used.

2 Likes

This is not what I need. There’s no way I know the files the user writes beforehand. I need classic.

I would like to ask if it’s acceptable to use this interface on the applications’s cache directory (e.g. ~/.cache/_app_id_)? In the case that the application doesn’t honour XDG_CACHE_HOME.

It’s not totally clear from this whether store approval is necessary for simply using this interface, or whether store approval is only needed for auto-connection of this interface. Can this interface be used without auto-connection with any directory? I am pretty sure the answer is no, it still needs store approval to release the snap at all

A snap declaration is required for use of the interface at all. Auto-connection would be a separate component of that snap declaration.

1 Like

I reviewed the docs, but can’t find how to see which files personal-files is a providing access to in a downloaded snap, or how to modify that list for an installed app. For example, I’m using the chromium snap on Ubuntu, and it seems to be not be able to read or write to ~/.local/share/icons which is required to make icons work when creating a “shortcut” .desktop file for a site.

I just upgraded the Chromium snap and all my custom apps using .desktop files broke. I believe this is because I can’t use symlinks in the Exec= line of those files, so hardcoded paths to specific snap versions are in there. When the snap version changes, all those references break.

The personal-files interface is declared by the snap and is unmodifiable by the user. The user may simply snap connect or snap disconnect the interface to allow/disallow the declared access. At some point, we may add the ability for admins to adjust the security policy beyond snap connect/disconnect, but that is not available today.

Furthermore, it is a current limitation of the feature that you cannot see what accesses are granted when connecting the personal-files interface, which is why as part of our approval process we require that the interface reference provide a clue to what is being granted. You can fetch the snap yaml like so prior to downloading (requires the http and jq snaps to be installed; there is probably a curl invocation that would achieve the same):

$ SNAPNAME=chromium ; http https://api.snapcraft.io/v2/snaps/info/$SNAPNAME Snap-Device-Series:16 fields==snap-yaml | jq -r '."channel-map"[0]."snap-yaml"'

name: chromium
...
plugs:
  ...
  chromium-config:
    interface: personal-files
    read:
    - $HOME/.config/chromium
...

Could it be that when I use a “descriptive interface reference”, (which this page says is needed for approval of the snap declaration for distribution via the store.) that causes it to not work for snaps installed from a local file? I’ll try declaring it without a descriptive reference. (Could this page usefully add an example showing how to do that?)

The “descriptive interface reference” is just for store approval, you can name the plug whatever you like while developing the snap locally, but note you will have to manually connect it. Then during the request for usage of the interface, a “descriptive interface reference” will be negotiated proposed and you will have to use that to upload your snap to the store.

1 Like

Here are some ideas that I think would improve this documentation page. Obviously ignore or correct these if my understanding is wrong:

  1. Be explicit that granting access to a directory does not grant access to the files in that directory. In order to do that, the snap author needs to grant access to each of the required files within the directory.

  2. If the application is written such that it first lists contents of a directory, and then opens the files it finds, then the snap author needs to grant read access to the directory itself, and then read or write access to the accessed files within that directory.

  3. If the application accesses arbitrary filenames within a directory (for example, my own application reads from “~/.ctags.d/*.ctags”, then the personal-files interface isn’t able to allow that. You have to explicitly list the filenames at snap build time, and wildcards are not supported.

  4. The page shows an example of a descriptive interface reference. Is there also a simpler way it could be expressed, without using a reference? Could an example of that be shown too? (I understand this could not be submitted for auto-connection.)

Granting access to a directory does grant access to the directory and all the files under it.

This is supported. Use:

plugs:
  dot-ctags:
    interface: personal-files
    write:
    - $HOME/.ctags.d
apps:
  foo:
    plugs:
    - dot-ctags

snapd itself supports:

plugs:
  personal-files:
    write:
    - $HOME/.ctags.d

but this is not allowed by our store review processes because it is not clear to the user of the snap what snap connect your-snap:personal-files is doing. Better is to use what I suggested above so the user does snap connect your-snap:dot-ctags.

I updated the documentation to include: “Specifying a directory in read and write allows access to the directory and all files under it.

I updated the documentation to include: “Specifying a directory in read and write allows access to the directory and all files under it.

1 Like

@jdstrand Thank you.

I think maybe some of my confusion stemmed from me not realizing $HOME is effectively set to $SNAP_USER_DATA for confined snaps. Because of this, nothing was working for me when I put the config file in /home/USER/.ctags.d.

If this is true, then I think this is also an important thing to mention here.