If you have connected the snap to the home interface this is expected as this interface allows access to non-hidden-files-directly-under-the-home-directory in the home directory(you can still list them, but any read attempt will fail).
I haven’t connect the home interface, just the personal-files but I can see and read everything in my home directory (including file in hidden folders). Strange as everything else works just fine 
You may want try to reproduce it with the gallery-dl snap, be sure to disconnect the home interface as it is default connected.
Good tip, thanks. Yes that seems to work correctly. With home disconnected, I can’t see anything in my real home dir. Do you know of any example snaps with personal-files working correctly that I could try?
Interestingly, I just noticed that if i connect home to gallery-dl and run a shell, I can read dot files :S
Ignore this! It’s because some of my dotfiles are symlinks to non-hidden locations 
Well the aforementioned gallery-dl snap is one of them, here’s the recipe:
Hmm ok thanks. So with home disconnected, I can’t read .config/gallery-dl because No such file or directory (it does exist, of course)
with home connected: Permission denied.
So it looks like there’s something strange going on.
That’s looks like something fishy is going on, what is the output of the snap version command in a terminal?
$ snap version
snap 2.38-1
snapd 2.38-1
series 16
arch -
kernel 5.0.4-arch1-1-ARCH
Also the output of snap debug sandbox-features would be nice.
1 Like
Sure
apparmor: kernel:caps kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default support-level:partial
confinement-options: classic devmode
dbus: mediated-bus-access
kmod: mediated-modprobe
mount: freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp: bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif
udev: device-cgroup-v1 tagging
oookay so I’m guessing the fact that strict isn’t listed in confinement-options is a concern…
Although I have plenty of strictly confined snaps installed so… like I said, I’m quite new to this 
1 Like
AFAICT the confinement are partially working under Arch, this means you may find something not confined as expecting.
So are the files under $HOME/.aws are accessible under the snap run --shell environment?
Ok so that’s not so bad. I think I can get this snap working once I’ve got $HOME pointing to the real home I’ll let you know soon!
1 Like
Ok, I’ve got it working, thanks for the help!
Here’s the snapcraft.yaml if you care to provide any feedback: https://github.com/stilvoid/aws-sam-cli/blob/add-snapcraft/snap/snapcraft.yaml
I cancel my request for classic confinement 
1 Like
test it on a distro that supports strict confinement though
2 Likes
Reading through this thread, it seems that use of personal-files for readonly access to ~/.aws should probably at least be granted a snap declaration for installation. I’m not sure yet if this interface should be auto-connected (~/.aws can contain some pretty sensitive data that could cost people money of if the data were stolen). That said, please continue working through make your snap function in strict mode and report back if you want to change your request from a request for classic to one of using personal-files.
I’m sorry, I missed that you revoked this request and requested personal-files in Requesting auto-connection of personal-files to sam-cli. I’ll respond over there.
1 Like