snapd sets the environment variable $HOME to $SNAP_USER_DATA when a command is executed. $SNAP_USER_DATA is something like /home/<user>/snap/<snap-name>/<snap-revision>, a path that’s writable by the snap. This works in most of the cases, except in go.

Side-stepping the discussion on the issues of maintaining /etc/passwd for new users across all the snaps, this change would make it difficult for snaps to find the real home, which a lot of snaps for classic distro using the home interface are interested in. Today, HOME is set to SNAP_USER_DATA (like you said) but snaps can and do use getent, getpwent(), getpwnam(), getpwuid(), etc to find the real home. Updating /etc/passwd would make all of those snaps break.

If this were going to be addressed, I think we’d want it opt-in so that existing snaps didn’t break. We’d probably also want to use a custom nss module instead of modifying /etc/passwd (since /etc/passwd may not even have the user in it).

// should be set in all UNIX by the OS. Alternatively, we fall back to

// usr.HomeDir (which should work on Windows etc.).

home := os.Getenv("HOME")

if home == "" {

usr, err := user.Current()

if err != nil {

panic(fmt.Sprintf("cannot get current user: %s", err))

}

home = usr.HomeDir

}

DefaultPath = filepath.Join(home, ".ipfs-cluster")

}

So, I guess that an option would be to accept that snaps are not fully transparent, for cases like this, and document best practices for upstreams to adjust their code to work with snaps.

Another such case that comes to mind is bitcoin, that requires a patch to save the blockchain to $SNAP_USER_COMMON instead of $SNAP_USER_DATA. This is not transparent because upstreams that want to save data will just do throw everything in $HOME; but we are introducing the concept of versioned and unversioned home, and they would have to adjust their source code to use it correctly.