sheltie: use /proc to find the bash binary

[samuelkarp]

Issue number:
Fixes #7

Description of changes:
Because we have a shared pid namespace, /proc inside the container matches /proc outside the container. The special directory 'root' inside a given process directory in /proc contains that process's view of the filesystem.

We can thus locate the container's root filesystem by taking advantage of the interpreter's /proc directory.

In order to make this work, we rely on the parent process existing in the container's mount namespace, so that the path we construct maps properly to the container's filesystem.

Testing done:
Tested locally with docker run -it --rm --privileged --pid=host. @etungsten tested it with Bottlerocket.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[samuelkarp]

@bcressey suggested using ${PPID} instead of $$ so that we can continue using exec. I didn't know about ${PPID}, but it represents the parent process ID of the current shell. I'm leaning against this as sheltie could be set as the entrypoint to the container and its parent process may not actually be in the same mount namespace.

[etungsten]

I've tested both the current changes and @bcressey's suggestions in a Bottlerocket instance with the admin container enabled and I'm able to reach the host root shell without problems:

[ec2-user@ip-192-168-31-58 ~]$ tail /bin/sheltie
# Because we have a shared pid namespace, /proc inside the container matches
# /proc outside the container.  The special directory 'root' inside a given
# process directory in /proc contains that process's view of the filesystem.
# We use $$ to indicate the pid of the interpreter running this script so we
# can see the container's root filesystem inside this directory.
ROOT_FS_PATH="/proc/$$/root"
BASH_PATH="/opt/bin/bash"

# Start the root shell on the Bottlerocket host
nsenter -t 1 -a "${ROOT_FS_PATH}${BASH_PATH}"
[ec2-user@ip-192-168-31-58 ~]$ sudo sheltie
bash-5.0# ls
bin  boot  dev  etc  home  lib  lib64  local  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  x86_64-bottlerocket-linux-gnu

=================================================================================

[ec2-user@ip-192-168-16-105 ~]$ tail /bin/sheltie
# Because we have a shared pid namespace, /proc inside the container matches
# /proc outside the container.  The special directory 'root' inside a given
# process directory in /proc contains that process's view of the filesystem.
# We use $$ to indicate the pid of the interpreter running this script so we
# can see the container's root filesystem inside this directory.
ROOT_FS_PATH="/proc/${PPID}/root"
BASH_PATH="/opt/bin/bash"

# Start the root shell on the Bottlerocket host
exec nsenter -t 1 -a "${ROOT_FS_PATH}${BASH_PATH}"
[ec2-user@ip-192-168-16-105 ~]$ sudo sheltie
bash-5.0# ls
bin  boot  dev  etc  home  lib  lib64  local  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  x86_64-bottlerocket-linux-gnu

[samuelkarp]

I'll update this to use @bcressey suggestion, since that works and fits the set of supported use-cases today. I am still concerned about ensuring that $PPID does correctly map to an in-container parent process, but the current implementation of host-ctr means that, at least for the admin container, we can rely on the entrypoint defined in the image. If we start supporting any of the following scenarios, we'll want to validate that this approach still works:

• customized entrypoint via host-ctr
• images derived from this admin image with a different entrypoint
• non-containerd runtimes

[zmrow]

🐤