Dotfile directories specified in command-line are not readable

[Gustaf Waldemarson]

Hello,

There appears to be some kind of permission issue with snap packages with the
"home" interface/connection enabled. E.g.,:

```
mkdir -p ~/.test/
mkdir -p ~/test/
echo "Hello, World!" > ~/.test/test.html
echo "Hello, World!" > ~/test/test.html
chmod -R 777 ~/.test/
firefox ~/.test/test.html # Works on Ubuntu 21.10 but not in 22.04.
chromium ~/.test/test.html # Fails on Ubuntu 21.10 and 22.04.
```

After debugging the above a bit, I realized that the main difference between
Ubuntu 22.04 and 21.10 is that Firefox uses a snap package in version 22.04 and
after testing a bit further, the same behaviour is present in at least Chromium,
Firefox and Gimp when trying to access a file inside of a 'hidden' (i.e.,
dotfile-directory) despite being situated inside the user home directory.

(I also tried this with Blender, but as that is a 'classic' snap, I guess it
circumvents the permission model)

However, I'm not sure if this is a bug or not. If this really is intended
behaviour though, the documentation (e.g.,
https://snapcraft.io/docs/interface-management ) should be updated to reflect
this and should additionally contain some not regarding how to disable this
'feature', since there are plenty of reasons to run applications inside of
dot-directories.

```
snap --version
snap 2.56
snapd 2.56
series 16
ubuntu 22.04
kernel 5.15.0-37-generic
```

[Alberto Mardegan (mardy)]

Hi Gustaf, and thanks for reporting this bug. This is a known (and wanted) limitation of the "home" interface: it does not grant access to hidden files.

I'm keeping your bug open because indeed it would make sense to automatically grant a snap some permissions to accesso those paths explicitly mentioned in the command line.

I also too the liberty of rewriting the bug title so that it's easier to find it for us.

[Gustaf Waldemarson (xaldew)]

Excellent! Thanks for confirming and adjusting the title to reflect the issue.

Just for completeness, is there any suggested workarounds for the time being? I did try to set at least Firefox in classic confinement with `snap refresh --classic firefox`, but that didn't seem to do anything in regard to accessing these directories at least

[Maciej Borzecki (maciek-borzecki)]

The --classic switch only acknowledges that you are installing a classic snap. Firefox is not a classic snap, so it has no effect.

[Jon Pryce (jpryce)]

This whole "home" safety thing with Snap is ridiculously overblown. HTML help files could be stored anywhere on the file system and should be openable by browsers like Firefox. This attitude is like "you are too stupid to work out what is safe to do so we are going to force you to do things our way". At the very least an administrator should be able to easily disable this check. In our case we make systems that are not even connected to the internet so there is absolutely no danger in allowing read access to system directories. In fact even if the systems were connected to the internet I fail to see what danger there could be in allowing read access to the local filesystem.

I am of course happy to be re-educated!

[Paul Weiß (poohl)]

Things broken by this on my system:
* rustup doc (tries to open the html-doc in .rustup)
* stm32cubeIDE doc (not a command, tries to open the html-doc stored in .stm32cubemx)