Invoking scuba with pwd at or above /home/$USER (on the host) will chmod it to 0700

[JonathonReinhart]

scubainit has code to create the user's home dir (in the container), originally the scubauser:
https://github.com/JonathonReinhart/scuba/blob/v2.11.0/scubainit/scubainit.c#L390-L409

It will unconditionally chmod(path, 0700) and chown(path, uid, gid).

Usually, this is not a problem because either:

• scuba is invoked from outside /home/$USER (on the host)
  • The created home directory is in the ephemeral container overlay, so it doesn't matter what scuba does to it.
• scuba is invoked from a subdirectory of /home/$USER (on the host)
  • The home directory was created in the container overlay by Docker as part of setting up the pwd bind mount, so it doesn't matter what scuba does to it.

But there is an unlikely corner-case:

• scuba is invoked directory in the /home/$USER
  • In this case, /home/$USER is the pwd, so it is bind mounted exactly in the container (at the same path).
  • Thus, when the chmod(path, 0700) runs, it actually affects the directory on the host.
  • I guess this would also happen if scuba were invoked in /home...

$ chmod 755 /home/jreinhart
$ ls -ld /home/jreinhart/
drwxr-xr-x 61 jreinhart jreinhart 4096 Sep  9 22:59 /home/jreinhart/

$ cd /home/jreinhart/
$ scuba --image debian:11 exit
$ ls -ld /home/jreinhart/
drwx------ 61 jreinhart jreinhart 4096 Sep  9 22:59 /home/jreinhart/

---

Note: We say /home/$USER rather than "the home directory" because $HOME could point somewhere else entirely, and this problem only applies to /home/$USER because that's what scubainit is currently hard-coded to use. (#216 is not yet implemented.)

[JonathonReinhart]

There is some history to this code:

• Implement writable home directory #57
  • bacbce4 Original implementation
• Use calling username/groupname instead of 'scubauser' #153
  • 6dee24d scubainit: Don't create home directory if it already exists
    • The commit message recognizes this problem:

      The mkdir_p is harmless, but the chmod/chown might actually affect the invoking user's home directory if .scuba.yml exists there.

  • 7bfd8bb scubainit: Pass mode=0755 to mkdir_p
• Fix non-writable home directory #169
  • ac7bc72 scubainit: Always chown home directory
    • ❗ I think this is where the bug was introduced. It effectively reverts 6dee24d and seemed to miss the logic in that commit message.

[JonathonReinhart]

My first thought was to simply remove the chown() call, since mkdir_p accepts a mode argument, which is used only if the directory is created. However:

• This is affected by the process umask.
• This would undo Fix non-writable home directory #169 and reintroduce the bug in Can't create files in home directory if working directory is under home #168.

---

When trying to identify a solution, I realized this problem also exists if scuba were invoked in /home (don't ask why anyone would do that):

• mkdir_p() would create nothing, as /home/$USER (presumably) already exists.
• chown() would modify the real (host) /home/$USER.

Going another step, if a user invoked scuba in /, this would also happen.

So I guess, before chowning the homedir, we need to answer the question:

• Is this the real home directory (from the host)? STOP, don't chown
• Or did docker create it as a parent for the pwd bind mount? PROCEED
• Or did scubainit create it? PROCEED

How do we determine if the path comes from the host? It's not as simple as asking "is this a bind mount", as noted above. I think we need to ask "is this directory, or any directory above it a bind mount?"

[JonathonReinhart]

Another weird corner case:

• scuba executed in /home or /
• real $HOMEDIR somewhere other than /home/$USER

When scubainit creates /home/$USER it will be created in the host /home/. Ugh.

Maybe we should just disallow running scuba in / or /home...