Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The launch.sh script and underlying container does not work if running as root on the host #181

Open
seansund opened this issue Jul 12, 2022 · 5 comments
Labels
bug Something isn't working

Comments

@seansund
Copy link
Member

No description provided.

@seansund seansund added the bug Something isn't working label Jul 12, 2022
@seansund
Copy link
Member Author

We should add -u "${UID}" to the run command so the container runs as the host user. Then they will have write permissions to the mounted volume

@timroster
Copy link
Contributor

Different container runtimes in play apply different host mounting strategies which may keep -u "${UID} from working consistently.

  • podman 4.1 mounts host volumes as root:nobody. need to see if this can be overridden.

  • Docker desktop tries to preserve the effective UID assumed in the container image as the volume file owner when this is not set. Unclear what happens when -u is specified, but a good suspicion is that it does the right thing.

  • colima does appear to preserve host uid in it's mapping so should work there

Although this addresses some of the potential issues with the host permissions, it raises other issues in the current cli-tools images because those have a $HOME within the container images owned by UID=10000 (devops):

/home/devops $ ls -al
total 40
drwxr-xr-x    1 devops   root          4096 Jul 12 16:08 .
drwxr-xr-x    1 root     root          4096 Jun 30 17:21 ..
-rw-r--r--    1 devops   root           833 Jun 30 17:21 .bashrc-ni
drwx------    4 devops   root          4096 Jun 30 17:21 .bluemix
-rw-r--r--    1 devops   root            53 Jun 30 17:16 .terraformrc
drwxr-xr-x    2 devops   root          4096 Jun 30 17:16 etc
-rwxr-xr-x    1 devops   root           833 Jun 30 17:16 image-message
drwxr-xr-x    1 501      dialout        128 Jul 12 16:07 src
drwxr-xr-x    2 devops   root          4096 Jun 30 17:16 terraform
/home/devops $ id
uid=501 gid=0(root)

@timroster
Copy link
Contributor

timroster commented Jul 12, 2022

With podman on MacOS - host mounts that show as root owned as part of the approach for rootless podman. When changing the configuration to rootful:

podman machine set --rootful

The host mount UID matches what is specified with -u option. However, using this option to proceed with apply fails with:

There are some problems with the CLI configuration:
╷
│ Error: The specified plugin cache dir /home/devops/.terraform.d/plugin-cache cannot be opened: stat /home/devops/.terraform.d/plugin-cache: no such file or directory
│
╵

As a result of the above problems, Terraform may not behave as intended.


Usage: terraform [global options] init [options]

  Initialize a new or existing Terraform working directory by creating
  initial files, loading any remote state, downloading modules, etc.

...

the same error appears with a simple terraform init down in the terraform source directory. These errors only seem to appear when running podman with rootful set using the cli-tools image.

Edit - It appears that even running the terraform version command gets broken when rootful containers are enabled for MacOS.

~ $ id
uid=501(501) gid=0(root)
~ $ terraform version
There are some problems with the CLI configuration:
╷
│ Error: The specified plugin cache dir /home/devops/.terraform.d/plugin-cache cannot be opened: stat /home/devops/.terraform.d/plugin-cache: no such file or directory
│
╵

As a result of the above problems, Terraform may not behave as intended.


Usage: terraform [global options] version [options]

  Displays the version of Terraform and all installed plugins

Options:

  -json       Output the version information as a JSON object.
Error parsing command-line flags: flag provided but not defined: -parallelism

This appears to being caused by an environment variable TF_CLI_ARGS='-parallelism=6' that is only appearing when rootful containers are enabled. When this is unset, terraform and apply.sh works as expected.

@timroster
Copy link
Contributor

This commit: cloud-native-toolkit/image-cli-tools@c9e799a fixes the environment variable causing issues with podman rootful and colima container engines. It just hasn't propagated to the image referenced in the launch.sh created by iascable

@timroster
Copy link
Contributor

On MacOS when using what appears to be the latest container image with fixes to TF_CLI_ARGS_apply for both podman (rootful) and colima: quay.io/cloudnativetoolkit/cli-tools:v1.2-v2.0.0

If the container is running as the host user by -u ${UID} there are failures when performing the terraform init directly or through apply.sh:

...
╷
│ Error: Failed to install provider
│ 
│ Error while installing hashicorp/null v3.1.1: mkdir /home/devops/.terraform.d: permission denied
╵
...

This is happening because the user from -u ${UID} does not have permissions in /home/devops in the container image. This can be fixed towards the end of the container image build chain (to cover any folders created by clis) with the addition of this command:

RUN chmod -R g=u /home/devops

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants