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

Running ansible-navigator from a non-root account causes error #1534

Open
noelmiller opened this issue May 17, 2023 · 4 comments
Open

Running ansible-navigator from a non-root account causes error #1534

noelmiller opened this issue May 17, 2023 · 4 comments
Labels
bug Researched, reproducible, committed to fix

Comments

@noelmiller
Copy link

ISSUE TYPE
  • Bug Report
SUMMARY

There is an issue with ansible-navigator or possibly podman when using the su or su - switching from the root user to an unprivileged user and attempting to run the ansible-navigator command.

ANSIBLE-NAVIGATOR VERSION
ansible-navigator 2.2.0
CONFIGURATION
ansible-navigator:
  execution-environment:
    image: ansible-automation-platform-22/ee-supported-rhel8:latest
    pull:
      policy: missing
  playbook-artifact:
    enable: false
LOG FILE

https://gist.github.com/noelmiller/410131a2ffc51e756bef00dcd8e9af0f

STEPS TO REPRODUCE
  1. Connect to ansible control node server using root account using ssh: ssh root@control-node
  2. Do one of the following to switch to the unprivileged user account:
    1. su user
    2. su - user
    3. su --login user
  3. Navigate to directory with relevant ansible-navigator.yml config
  4. Run ansible-navigator (or any subcommand)
  5. You will receive the error I listed above
EXPECTED RESULTS

Expect the interactive ansible-navigator tui to appear, but instead I get the error below.

ACTUAL RESULTS
-------------------------------------------------------------------------------------------
Execution environment image and pull policy overview
-------------------------------------------------------------------------------------------
Execution environment image name:     ansible-automation-platform-22/ee-supported-rhel8:latest
Execution environment image tag:      latest
Execution environment pull arguments: None
Execution environment pull policy:    missing
Execution environment pull needed:    True
-------------------------------------------------------------------------------------------
Updating the execution environment
-------------------------------------------------------------------------------------------
Running the command: podman pull ansible-automation-platform-22/ee-supported-rhel8:latest
WARN[0000] RunRoot is pointing to a path (/run/user/1000/containers) which is not writable. Most likely podman will fail.
Error: default OCI runtime "crun" not found: invalid argument
  Error: Execution environment pull failed
   Hint: Check the execution environment image name, connectivity to and
         permissions for the registry, and try again
ADDITIONAL INFORMATION

This could be an issue with podman itself, I did find another resolved github issue talking about switching user from root to unprivileged user here: containers/podman#8052

@noelmiller noelmiller added bug Researched, reproducible, committed to fix new New issues and PRs to triaged labels May 17, 2023
@noelmiller
Copy link
Author

noelmiller commented May 18, 2023

Update

I did some additional testing today and I think this is an issue with podman itself and not necessarily ansible-navigator.

Podman Version

podman version 4.4.1

OS Version

Red Hat Enterprise Linux release 9.1 (Plow)

STEPS TO REPRODUCE

  1. Connect to ansible control node server using root account using ssh: ssh root@control-node
  2. Do one of the following to switch to the unprivileged user account:
    1. su user
    2. su - user
    3. su --login user
  3. Run podman run docker.io/hello-world

Expected Results

Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob 719385e32844 done
Copying config 9c7a54a9a4 done
Writing manifest to image destination
Storing signatures

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Actual Results

When running after su user

ERRO[0000] XDG_RUNTIME_DIR directory "/run/user/0" is not owned by the current user

When running after su - user

WARN[0000] RunRoot is pointing to a path (/run/user/1000/containers) which is not writable. Most likely podman will fail. Error: default OCI runtime "crun" not found: invalid argument

When running after su --login user

WARN[0000] RunRoot is pointing to a path (/run/user/1000/containers) which is not writable. Most likely podman will fail. Error: default OCI runtime "crun" not found: invalid argument

@noelmiller
Copy link
Author

noelmiller commented May 18, 2023

One more additional thing I will add.

When you login directly over SSH as the unprivileged user, it does map the XDG_RUNTIME_DIR correctly and the container will pull or run properly.

ssh user@ansible-control-node

echo $XDG_RUNTIME_DIR
/run/user/1000

podman run docker.io/hello-world
Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob 719385e32844 done
Copying config 9c7a54a9a4 done
Writing manifest to image destination
Storing signatures

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

When doing a su user from the root user, it does not map the XDG_RUNTIME_DIR correctly. It is mapped to the root user's value.

echo $XDG_RUNTIME_DIR
/run/user/0

When doing a su - user from the root user, it does not map the XDG_RUNTIME_DIR at all, it's completely blank

echo $XDG_RUNTIME_DIR

When doing a su --login user from the root user, it does not map the XDG_RUNTIME_DIR at all, it's completely blank

echo $XDG_RUNTIME_DIR

If you attempt to map the XDG_RUNTIME_DIR manually, it still gives a similar error

XDG_RUNTIME_DIR=/run/user/1000

echo $XDG_RUNTIME_DIR
/run/user/1000

podman run docker.io/hello-world
WARN[0000] Failed to get rootless runtime dir for DefaultAPIAddress: lstat /run/user/1000: no such file or directory
WARN[0000] RunRoot is pointing to a path (/run/user/1000/containers) which is not writable. Most likely podman will fail.
Error: default OCI runtime "crun" not found: invalid argument

@noelmiller
Copy link
Author

Final update and I will take a break from troubleshooting this. It appears to me that it is potentially a problem with the su command and how it interacts with environment variables related to podman.

I just did a test where I have 2 unprivileged users (bob and sally) and I use the su, su - [username] commands to switch between those users and it mimics the issues I was having from switching from the root account to a user account where it does not properly remap the XDG_RUNTIME_DIR variable (among other things probably)

When doing a su sally from the bob user, it does not map the XDG_RUNTIME_DIR correctly. It is mapped to the bob user's value.

echo $XDG_RUNTIME_DIR
/run/user/1001 # bob's value

When doing a su - sally from the bob user, it does not map the XDG_RUNTIME_DIR at all, it's completely blank

echo $XDG_RUNTIME_DIR

@noelmiller
Copy link
Author

noelmiller commented May 18, 2023

It appears the podman team is aware of this bug and looking for a better way to warn users of the potential pitfall of using su or sudo to run rootless podman: containers/podman#14603

I personally would like to understand why there can't be a permanent fix for this issue or what is preventing su working properly with podman

@shatakshiiii shatakshiiii removed the new New issues and PRs to triaged label May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Researched, reproducible, committed to fix
Projects
Status: No status
Development

No branches or pull requests

2 participants