Question
personal-files Access to Excluded Home Dot-directories for Strict Snaps
Dev Atlas
0 reputation · 22 Jul 2020, 13:07 UTC
127.8K views1
Loading…
0 reputation · 22 Jul 2020, 13:07 UTC
Let a strictly confined snap access a sensitive dot-directory under $HOME, such as .ssh or .gnupg, through the personal-files interface without connecting the full home interface.
Constraints: the home interface is usually auto-connected but excludes credential locations. personal-files can expose those paths, but it is not auto-connected and must be approved per snap. No documented system-wide default balances application workflow against credential exposure, and the exclusion list differs across Ubuntu releases and snapd versions.
Assumption: recent Ubuntu LTS with snapd strict confinement. The applicable confinement mode and interface set must be checked on the target system before any grant.
Specific questions:
35275 reputation · 22 Jul 2020, 19:35 UTC
Approve personal-files per snap plug, limited to the narrow paths declared by that snap. Do not establish a system-wide default. The approval is not independently “per directory”: the snap’s plug declaration supplies the read/write paths. If it declares broad write access to $HOME/.ssh or $HOME/.gnupg, connecting that plug exposes that broad scope; snap connect cannot impose a narrower directory restriction. Request a revised plug declaration if the publisher’s scope is excessive.
Adding personal-files does not disconnect an already connected home plug. If policy requires home to remain disconnected, disconnect it explicitly only after confirming that the application does not depend on it.
ubuntuhome is commonly auto-connected for strict snaps, while personal-files is normally not auto-connected.The home interface’s excluded locations are not a stable cross-release contract. Credential-related dot-directories have been handled differently across Ubuntu and snapd versions. That likely explains inconsistent behavior between systems. Treat the target host’s installed snapd, interface metadata, and effective confinement profile as the source of truth rather than copying another release’s assumptions.
Do not expose a credential-bearing excluded directory wholesale. Prefer a dedicated, application-owned configuration directory containing no secrets, with read-only access when sufficient. A single $HOME/.ssh/known_hosts file is lower risk than exposing .ssh, but it can disclose infrastructure hostnames, so it still needs a concrete purpose.
Avoid private keys, .gnupg, cloud credentials, Kubernetes or Docker authentication files, keyrings, secret-service stores, token-bearing configuration files, and browser profiles. These are examples of sensitive categories, not a verified exclusion list for any particular release.
snap version
snap interfaces <snap-name>
snap connections <snap-name>
snap interface personal-files
snap interface home
snap info <snap-name>
snap debug confinement <snap-name>Record the exact plug name and its declared read/write paths. The snap debug confinement command may not exist on every installed snapd version; in that case, inspect the snap’s plug declaration and generated AppArmor profile through the available local tooling.
If the declaration is appropriately narrow, connect that specific plug:
sudo snap connect <snap-name>:<plug-name>
snap connections <snap-name>Test only the intended path using non-secret data, preferably through the application’s own functionality. Repeat the checks after a snap refresh or Ubuntu/snapd upgrade. When access is no longer required:
sudo snap disconnect <snap-name>:<plug-name>For a path-specific verdict, the one missing diagnostic detail is the target snap’s personal-files plug declaration showing its read/write paths.
Use comments to ask for clarification. Post a solution as an answer.
6,610 reputation · 22 Jul 2020, 17:35 UTC
Personal-files plugs are defined in a snap’s metadata with exact paths, not wildcards, so you must list each dot-directory you need (e.g., /home/username/.ssh) individually; the home interface exclusion list is snapd‑version dependent and can change between Ubuntu LTS releases, meaning a grant that works on one release may be blocked on another. Verify the current exclusion list with snap interfaces and confirm read‑only access is sufficient before granting write permissions.