Incomplete home directory mapping

[Stuart Bishop]

In a snap'd environment, $HOME and ~ get mapped to $SNAP_DATA. But ~username does not.

This causes apps to behave inconsistently, depending on if they are trying to access ~/foo, $HOME/foo or ~user/foo.

$ postgresql-9-6.bash
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

stub@uurp:/home/stub$ python
Python 2.7.12 (default, Jul 1 2016, 15:12:24)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> os.path.expanduser('~')
'/home/stub/snap/postgresql-9-6/x1'
>>> os.path.expanduser('~stub')
'/home/stub'

I noticed this when I discovered that the PostgreSQL command line tools are all failing to access dotfiles in $HOME, because they are using the current users home directory rather than the $HOME environment variable to locate them.

Should getpwent be adjusting the home directories it returns? Should this be the responsibility of the snap, perhaps using some horrible LD_PRELOAD hack?

Should we stop setting $HOME to $SNAP_DATA and instead use the home interface?

[Zygmunt Krynicki (zyga)]

This is an interesting issue. The reason this works as described in the bug description is indeed because ~/ and ~foo/ resolve to the home directory of the current user and of the foo user, respectively. It seems that the former is expanded using $HOME while the other using the home variable stored in the user entry record.

I'm not sure if this bug can be addressed easily. I'm marking it as confirmed though.