Re-implement scubainit

[JonathonReinhart]

TL;DR

Implement a scubainit executable that is the overriding ENTRYPOINT for the container.

History

• Experienced issue Unknown user ID in container #11 (Unknown user ID in container)
  • Fixed via Add .scubainit #13 (add .scubainit)
• Experienced issue Control+C weirdness running Debian images #22 (Control+C weirdness)
  • Fixed via Inject /etc/passwd and friends instead of .scubainit #24 (Inject /etc/passwd and friends instead of .scubainit)

I think .scubainit was a cool idea, and generally accomplished the goal of performing arbitrary setup inside the container, before launching the user command.

The real problem however was that su forks and execs the given command, which prevents signals from Docker from being forwarded correctly (see the extended commentary in #22).

I went back to c71040b, before #24 was merged, and played with the following alternatives to emitting su <user command> in the .scubainit script. They all "worked", as far as avoiding the Ctrl+C weirdness:

• write_cmd(*command) -- Simply run the user command from .scubainit
  • This one implies that the process doesn't need to be PID 1, but nothing else. I think where Docker forwards signals to the container PID 1, the shell will forward them on to the child process.
• write_cmd('exec', *command) -- exec the user command from .scubainit
• write_cmd('/suexec', SCUBA_USER, *command)
• write_cmd('exec', '/suexec', SCUBA_USER, *command)
  • These two used a simple C program I wrote to perform the user switch and exec, called suexec

Going Forward

scuba will provide a statically-linked program called scubainit which will be bind-mounted into the container. scubainit will be passed as the --entrypoint to docker run. It will:

• Create the scubauser group and user
• Set the umask to that of the host
• Run any .scuba.yml-defined pre-exec hooks (future feature)
• setgroups, setgid, setuid to that of the host
• execvp() its argv which is the user COMMAND

scuba will set the following environment variables, which scubainit will consume and unset before executing the user command:

• SCUBAINIT_UID - The UID of the host process, to be set for scubauser
• SCUBAINIT_GID
• SCUBAINIT_UMASK
• SCUBAINIT_HOOK - Path to a script to execute before executing the user command (future feature)

Challenges

Docker images are always Linux, so it should be straightforward to accomplish this on a Linux host. But:

• Will scubainit need to be compiled during invocation of setup.py?
• What about OSX or Windows hosts?
  • Granted, since they use a boot2docker VM (for now), we don't even bother with the whole scubauser thing - we just let the user command run as root, and (on OSX anyway), because of how they do the home directory sharing with VirtualBox, the files end up owned by the invoking user.
  • But, we'll miss out on the SCUBAINIT_HOOK without scubainit. Maybe we can include a pre-compiled version in the PyPi package?

[JonathonReinhart]

I'm struggling to understand what to do with this scubainit binary.

• Do I have a top-level Makefile that builds it, and plops it into the right location for deploying to PyPi?
• Where does it live for testing?
• How do I include it in setup.py?
• How do I find its path at runtime?

Resources:

• http://stackoverflow.com/questions/7522250
• http://stackoverflow.com/questions/24642788

[JonathonReinhart]

Closed via PR #49