Home directory points to snap volume

[ksilin]

When mounting volumes with docker-compose, I expect paths like ~/.config and $HOME/.config to point to the home directory of the current user.

Currently, these paths point to the snap volume, e.g. /home/ksilin/snap/docker/471/.config. This is unexpected and makes mounting from current user's home directory non-portable.

[tianon]

I've looked, and there isn't anything specific we're doing to set HOME (for either docker or dockerd), so I think this is an unfortunate quirk of Snappy.

I think we could possibly do something with a wrapper script that sets HOME=$SNAP_REAL_HOME, but I don't know whether that would be enough to fix this (it depends on whether Compose is trusting $HOME or doing a lookup).

You should also be able to use $SNAP_REAL_HOME, but actually using it will require connecting :home (same as if we change HOME to point to that value, which is what makes me hesitate to change it because there are likely users relying on this, especially since Docker puts things in $HOME/.docker like registry auth).

[ksilin]

Thank you for looking into it, @tianon. Unfortunately, I do not know how Compose resolves ~ or $HOME. I cannot switch to using other variables since it's a shared script which is supposed to be portable. Do you think you can give a 'naive' solution a try to see whether it works with a reasonably current version of docker/docker-compose?

[anonymouse64]

actually using it will require connecting :home

the home interface should already be connected for the docker snap on all systems, but I agree that simply changing the value of $HOME for the snap will probably regress some users of the snap, and also will break in the sense that if anything tries to write to $HOME/.docker/... that will now fail because dotfiles in the home directory cannot be accessed with the home interface. To access these paths, one would need to use the personal-files interface, and while the docker snap could be reasonably granted access to ~/.docker, it's not at all clear that the docker snap is the owner of ~/.config/... and so allowing that personal-files interface would probably be denied.

[ksilin]

I might be misunderstanding the permissions here - isn't dockerd running as root and the containers with the current user's permissions and thus should have the permissions for the current user's home?

[anonymouse64]

No, all snaps are denied access to dotfiles in user's home directories by design. The only exception is by using a personal-files interface.

Also technically speaking yes normally the dockerd daemon running as root will not have permission to read user's home directories, however the docker snap has a variant of the home interface that specifies the read: all attribute and thus is able to read non-root user's home directories (but still not dotfiles in those home directories unless a corresponding personal-files interface is used)

[nickbreen]

I think I just ran into this when attempting to use bazel to build images with rules_docker.

Bazel, by default, stores all its outputs and various working files in ~/.cache/bazel/.

I assume that ~/.cache is classified as "personal-files".

[qins]

While snap Docker is not ideal, it offers increased security by limiting access to one's own home directory.
The best approach is to evaluate your specific use case and choose the option that best aligns with your priorities.