tmpfs mount for host $HOME path in OCI mode container with different USER in container

[nathanweeks]

When running an OCI container that was created from a Dockerfile containing a USER instruction, where the specified user in the container has a different $HOME path than the host user, SingularityCE 4.2.2 still defaults to mounting a tmpfs at a path inside the container corresponding to $HOME on the host; e.g., on Rocky Linux 8.10, given the following Dockerfile (based on the example at https://docs.sylabs.io/guides/4.2/user-guide/oci_runtime.html#pulling-and-running-oci-containers):

$ singularity --version
singularity-ce version 4.2.2-1.el8
$ cat Dockerfile 
FROM alpine
RUN addgroup -g 2000 testgroup
RUN adduser -D -u 2000 -G testgroup testuser
USER testuser
RUN echo "content" >  /home/testuser/file.txt
$ singularity build --oci test.sif Dockerfile 
...

A container that uses this OCI-SIF has a tmpfs mounted at /home/rocky (in this case) that isn't writable by the USER specified in the Dockerfile (due to differing uid/gid):

$ echo $HOME
/home/rocky
$ id -u
1000
$ id -g
1000
$ singularity exec --oci test.sif sh -xc 'ls -l $HOME; ls -ld /home/rocky; df -h $HOME /home/rocky'
INFO:    System configuration does not support cgroup management - starting container in current cgroup
+ ls -l /home/testuser
total 0
-rw-r--r--    1 testuser testgroup         8 Jan  9 21:44 file.txt
+ ls -ld /home/rocky
drwxr-xr-x    2 1000     1000            40 Jan  9 21:53 /home/rocky
+ df -h /home/testuser /home/rocky
Filesystem                Size      Used Available Use% Mounted on
overlay                  64.0M         0     64.0M   0% /
tmpfs                    64.0M         0     64.0M   0% /home/rocky

This default doesn't seem overly useful, though I suppose would it would normally be innocuous (if exposing the pathname of the home directory on the host isn't a concern). Except on a Rocky Linux 8.9 cluster with NFS-mounted home directories (but not the standalone VM used in the above example), I encountered an error pertaining to this tmpfs mount when the Dockerfile contained USER root (which could be worked around with --fakeroot or --no-home as demonstrated below):

$ cat Dockerfile 
FROM alpine
USER root
$ XDG_RUNTIME_DIR=$(mktemp -d) singularity build --oci test.sif Dockerfile
...
$ singularity exec --oci test.sif pwd
INFO:    System configuration does not support cgroup management - starting container in current cgroup
INFO:    No /run/user session directory for user. Using "/tmp/singularity-oci-1000" for runtime state.
2025-01-09T22:10:42.780587Z: mount `tmpfs` to `home/myuser`: Invalid argument
$ singularity exec --fakeroot --oci test.sif pwd
INFO:    System configuration does not support cgroup management - starting container in current cgroup
INFO:    No /run/user session directory for user. Using "/tmp/singularity-oci-1000" for runtime state.
/
$ singularity exec --no-home --oci test.sif pwd
INFO:    System configuration does not support cgroup management - starting container in current cgroup
INFO:    No /run/user session directory for user. Using "/tmp/singularity-oci-1000" for runtime state.
/

Before going through the effort of attempting to track down the root cause of the error (if it isn't already obvious to the SingularityCE developers), I was wondering if the tmpfs mount based on the home directory path on the host is warranted in this case, or could be "optimized" away by default?