autopkg / smithjw-recipes

Smithjw's AutoPkg recipes
Apache License 2.0
14 stars 16 forks source link

Docker 2.15.0 changes that will affect deployments #29

Closed Daz-wallace closed 1 year ago

Daz-wallace commented 1 year ago

Hi,

There are some changes from the Docker devs that will affect deployments, and specifically the postflight script you use here - https://github.com/autopkg/smithjw-recipes/blob/master/Docker/scripts/postinstall

With the release of 2.15.0, the docker binary is no longer able to be called as root as mentioned in this area of the documentation

Versions prior to Docker Desktop 4.15, require root access to be granted on the first run. The first time that Docker Desktop is launched the user receives an admin prompt to grant permissions for a privileged helper service com.docker.vmnetd to be installed. For subsequent runs, no root privileges are required. This approach allowed, following the principle of least privilege, root access to be used only for the operations for which it is absolutely necessary, while still being able to use Docker Desktop as an unprivileged user. All privileged operations are run using the privileged helper process com.docker.vmnetd.

For security reasons, starting with the version 4.15, Docker Desktop for Mac does not require the user to run a permanent privileged process. Whenever elevated privileges are needed for a configuration, Docker Desktop prompts the user with information on the task it needs to perform. Most configurations are applied once, subsequent runs do not prompt for privileged access anymore. The only time Docker Desktop may start the privileged process is for binding privileged ports that are not allowed by default on the host OS.

-- https://docs.docker.com/desktop/mac/permission-requirements/#permission-requirements

With the same line you use in your postflight (/Applications/Docker.app/Contents/MacOS/Docker --unattended --install-privileged-components) the installer seems to hang. Once fully quit and relaunched we've seen users who's Docker install will either fail to launch at all, or freeze shortly after launch.

With a fresh Docker GUI install (drag and drop), followed by manually running the --install-privileged-components command this is stopped with the following output: Untitled

After launching Docker Desktop, there's new admin prompts to setup a symlink and create a startup item:

Screenshot 2022-12-02 at 14 11 17

Even with manually creating these in advance, it seems to still not be happy and will re-prompt.

After some amount of digging, I found there is a different command that has been present since Docker Desktop v4.11.x that may help:

In version 4.11 and later of Docker Desktop for Mac, privileged configurations are applied during the installation with the --user flag on the install command. In this case, the user is not prompted to grant root privileges on the first run of Docker Desktop. Specifically, the --user flag:

  • Uninstalls the previous com.docker.vmnetd if present
  • Sets up symlinks for the user
  • Ensures that localhost is resolved to 127.0.0.1

This approach has the limitation that Docker Desktop can only be run by one user account per machine, namely the one specified in the -–user flag.

I have managed to successfully use this in a post-install script for 1:1 devices with the below lines:

        currentUser="$(/usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | /usr/bin/awk '/Name :/ && ! /loginwindow/ { print $3 }')"
        "/Applications/Docker.app/Contents/MacOS/install" --user "${currentUser}"

For my needs, this is good enough, but I'm guessing might need to be triggered frequently or differently for multi-user environments.

Anyway, thought I'd share my findings incase they prove useful.

Enjoy!

kevinmcox commented 1 year ago

Thanks for writing up this issue @Daz-wallace. --accept-license is another flag we're going to add to our Munki postinstall to avoid the user being prompted to accept the first time they launch Docker.