"/home" should be configurable

At the moment, the path prefix "/home" is hardwired into snapd in a number of locations, e.g.

$ git clone https://github.com/snapcore/snapd.git
$ cd snapd/
$ find * -type f -print0 | xargs -r0 fgrep -H '"/home'
cmd/snap-confine/mount-support.c: {"/home"}, // to support /home/*/snap and home interface
cmd/snap-confine/user-support.c: if (errno == EROFS && !sc_startswith(user_data, "/home/")) {
cmd/snap/cmd_run_test.go: filepath.Join("/home/foo/ws/snapd/snap"),
dirs/dirs.go: SnapDataHomeGlob = filepath.Join(rootdir, "/home/*/", UserHomeSnapDir)
errtracker/errtracker.go: if strings.Contains(p, "/home") || strings.Contains(p, "/tmp") {
interfaces/apparmor/spec.go: return strings.HasPrefix(path, "/var/snap/") || strings.HasPrefix(path, "/home/") || strings.HasPrefix(path, "/root/")
interfaces/builtin/personal_files_test.go: {`read: [ "/home/@{HOME}/foo" ]`, `"/home/@{HOME}/foo" contains a reserved apparmor char from .*`},
interfaces/builtin/system_files_test.go: {`read: [ "/home/$HOME/foo" ]`, `\$HOME cannot be used in "/home/\$HOME/foo"`},
interfaces/builtin/system_files_test.go: {`read: [ "/home/@{HOME}/foo" ]`, `"/home/@{HOME}/foo" contains a reserved apparmor char from .*`},
osutil/nfs_linux.go: if (entry.FsType == "nfs4" || entry.FsType == "nfs" || entry.FsType == "autofs") && (strings.HasPrefix(entry.MountDir, "/home/") || entry.MountDir == "/home") {
osutil/nfs_linux.go: if (entry.Type == "nfs4" || entry.Type == "nfs") && (strings.HasPrefix(entry.Dir, "/home/") || entry.Dir == "/home") {

Would it not be possible to simply remove all occurrences of the string "/home" from the C and Go source code, and make is a run-time configuration variable? Or at least have an optional second home-directory path prefix that can be added at run-time as a configuration option?

For example something that can be set

* on the command line, as in

    /usr/lib/snapd/snapd --home-prefix=/home

* via a system options, such as

    snap set system home-prefix /home

Ideal would be if a system-administrator should set that option persistently by just adding a new file to an existing system.

AppArmour profiles do this already via /etc/apparmor.d/tunables/home, so why can't snapd?

Use of the prefix "/home" for home directory paths is incompatible with very common practice in centrally managed systems where home-directories are automounted from NFS servers.

For example, in our particular system (Department of Computer Science and Technology, University of Cambridge, several hundred users and workstations), the setup if as follows:

$ getent passwd mgk25
mgk25:*:1597:1597:Markus Kuhn:/home/mgk25:/bin/bash
$ echo $HOME
/home/mgk25
$ ls -l /home
lrwxrwxrwx 1 root root 5 Oct 22 23:35 /home -> homes
$ ls -l /homes
lrwxrwxrwx 1 root root 11 Oct 13 2008 /homes -> /auto/homes
$ ls -ld /auto/homes/mgk25
drwxr-xr-x 223 mgk25 mgk25 65536 Oct 23 17:02 /auto/homes/mgk25
$ findmnt $HOME
TARGET SOURCE FSTYPE OPTIONS
/auto/homes/mgk25 wulbor.cl.cam.ac.uk:/userfiles/mgk25/unix_home nfs4 rw,relatime,vers=4.1,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=krb5p,clientaddr=2001:630:272:238:3656:c6fd:1234:5678,local_lock=none,addr=2a05:b400:110:a9::4321:abcd
$ findmnt /auto/homes
TARGET SOURCE FSTYPE OPTIONS
/auto/homes auto_homes autofs rw,relatime,fd=12,pgrp=1417,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=31648
$ cd ~ ; pwd -P
/auto/homes/mgk25

In other words:

- my $HOME contains two symbolic links in its path

- my $HOME is auto-mounted via either NFSv3 or NFSv4.1 using Kerberos authentication (sec=krb5p)

- my $HOME actually resides under /auto/homes/

The reasons we have these two symbolic links:

- /home -> /homes This link is in place on LAN-connected computers, where all
  home directories are on the filer, to avoid local state on the local disk (which
  can die any minute and is not backed up). However, on mobile computers, users may
  have a local home directory under /home, and they still can access their automounted
  filer-based home directories under /homes

- /homes -> /auto/homes Past experience has shown that auto-mounting /homes directly in the
  root direxctory / can cause the entire root directory to block, and if '/' blocks,
  everything locks up quickly, and the machine becomes unresponsive. Moving all automounts
  into a subdirectory /auto of the root directory solved that problem, i.e. local OS components
  that do not depend on the NFS home directories continue to work fine if the central
  filer has a hick-up, and many things (e.g. sshd into a local home) still work fine.

So there are qite good reasons for the current setup that we are not keen to give up just to be able to use snaps.

I wonder: if there simply were a global configuration option for snapd that would allow me to replace the currently hard-wired path prefix "/home" with e.g. "/auto/homes", would all my current snap troubles would go away?

Current snap troubles:

a) snaps do not get "network inet/inet6" permissions, and therefore can't do NFS (the
   attempted fix in https://github.com/snapcore/snapd/pull/8936/files just added
   another hardwired occurence of "/home").

b) if I manually override a) in AppArmor as described in bug #1662552, then I get

cannot perform operation: mount --rbind /home /tmp/snap.rootfs_NnRQQa//home: Permission denied

(Is the latter error because /home is a symlink?)