The personal-files interface

doc
1

The personal-files interface provides access to specified files in the user’s home directory, and consequently, gives privileged access to the user’s data.

This interface is typically used to provide read-only access to top-level hidden data directories (directories starting with a dot) 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.

By default, snaps have access to everything under ~/snap/<snap name>/<revision> and it’s this path stored in the $SNAP_USER_DATA environment variable. For non-daemon commands within the snap, this location is also where the $HOME environment variable points to, and where they can read and write to hidden files freely.

Requires snapd version 2.37+.

Interface documentation:

See Interface management and Supported interfaces for further details on how interfaces are used.

Developer details

Auto-connect: no
Super-privileged: yes
Transitional: 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. If there are missing directories between $HOME and the target file or directory, these are created automatically when the associated application is first run by a non-root user.

Approval process

For distribution via the Snap store, snaps that use the personal-files interface need an approved snap declaration. For acceptance, the publisher needs to make a descriptive interface reference, as used by snap connections|interfaces|connect|disconnect commands.

Code examples

If a foo application is being packaged as a snap and its publisher wants the snap to:

  1. Import an existing configuration from ~/.config/foo into $SNAP_USER_DATA/.config/foo (ie, $HOME/.config/foo within the snap’s runtime environment or ~/snap/foo/<revision>/.config/foo) on the host)
  2. Save user-specific data in $HOME/.local/share/foo, where $HOME/.local and $HOME/.local/share/ will be automatically created for the calling user if it does not exist

The snapcraft.yaml could include the following:

name: foo
...
plugs:
  dot-config-foo:
    interface: personal-files
    read:
    - $HOME/.config/foo
  dot-local-share-foo:
    write:
    - $HOME/.local/share/foo

apps:
  foo:
    plugs:
    - dot-config-foo
    slots:
    - dot-local-share-foo
    ...

When declaring an instance of the personal-files plug or slot, it should be named with a descriptive name that indicates to a user what access it grants. In the above example, dot-config-foo is used to reflect the access to ~/.config/foo, and dot-local-share-foo is used to reflect the access to ~/.local/share/foo.

You would then be able to use the following to enable access to personal files:

snap connect foo:dot-config-foo
2 Likes
2

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

3

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.

4

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

5

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
6

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.

7

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
...
10

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?)

11

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
12

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.)

13

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.

14

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

15

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
16

@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.

17

Based on this, does it mean that I will need something other than $HOME if I want to really access the files in a user’s home directory? Thanks for all the discussion you have done on this issue. The documentation is very confusing!

1 Like
18

there needs to a way to see which personal files required for snap without digging through yaml file, like cli or snapstore gui.

19

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

Is ./a/b/c under ./a? I’d say yes, but a read: [a] does not allow that, does it? Isn’t s/under/in/ clearer then, or even a explicit statement, such as

Specifying a directory in read and write allows access to the directory and all files in it, but not to its subdirectories’ files.

20

small typo there, can .lcoal be renamed to .local?

21

Absolutely - fixed now, thanks for letting us know!