Getting PAM sudo error trying to use this container

[artis3n]

I am using this within Molecule tests, but I can reproduce my error directly on the container. I do not often use CentOS-like distros so I am not sure what may have recently changed to trigger the following error.

Running any sudo command inside the container fails with the following error message:

sudo: PAM account management error: Authentication service cannot retrieve authentication info
sudo: a password is required

This breaks my Molecule tests at a DNF install task:

- name: CentOS | DNF Dependencies
  become: true
  ansible.builtin.dnf:
    name: "{{ deps}}"
    state: present

To reproduce:

Start the container:

docker run -i --entrypoint=bash --privileged --volume=/sys/fs/cgroup:/sys/fs/cgroup:rw --cgroupns=host geerlingguy/docker-rockylinux9-ansible:latest
# Simpler run invocation also results in the error
docker run -it --rm --entrypoint=bash geerlingguy/docker-rockylinux9-ansible:latest

Inside the container, run any sudo command:

[root@25c3908841c3 /]# sudo "hello world"
sudo: PAM account management error: Authentication service cannot retrieve authentication info
sudo: a password is required

The Ansible playbook does not assume it is invoked by the root user, so I need to keep the become: true annotation on my task.

This also happens on your Rocky Linux 8 ansible container.

Simply running docker run -it --rm rockylinux/rockylinux:9-ubi and installing sudo inside it (dnf install sudo) does not result in this error - sudo works fine.

However, I can reproduce it on the base RockyLinux 9 image after running the install steps in this Dockerfile:

[root@0e0e63dcef42 /]# yum -y install rpm dnf-plugins-core \
 && yum -y update \
 && yum -y install \
      epel-release \
      initscripts \
      sudo \
      which \
      hostname \
      libyaml \
      python3 \
      python3-pip \
      python3-pyyaml \
      iproute \
 && yum clean all
# ...
Complete!
25 files removed
[root@0e0e63dcef42 /]# sudo echo "hello world"
sudo: PAM account management error: Authentication service cannot retrieve authentication info
sudo: a password is required

This minimal install script also reproduces the issue:

[root@0e0e63dcef42 /]# yum -y install rpm dnf-plugins-core \
 && yum -y update \
 && yum -y install sudo
# ...
Complete!
[root@662fd0b1f977 /]# sudo echo "hello world"
sudo: PAM account management error: Authentication service cannot retrieve authentication info
sudo: a password is required

But yum install sudo (without -y) makes sudo function correctly.

docker run -it --rm rockylinux/rockylinux:9-ubi

[root@d9aaeccdd87e /]# yum install sudo
# ...
Installed:
  sudo-1.9.5p2-10.el9_3.x86_64                                                                                                                                                                              

Complete!
[root@d9aaeccdd87e /]# sudo echo "hello world"
hello world

This is as far as I got right now - I'll keep tinkering and send up a fix PR once I figure out why this is happening. But wanted to raise this up as an FYI as well.

[artis3n]

Narrowed it down a little further:

yum -y update && yum install sudo # results in the PAM error

I see pam is upgraded during the update command, which is my guess on why this is happening.

Upgraded:
  libsemanage-3.6-2.1.el9_5.x86_64    p11-kit-0.25.3-3.el9_5.x86_64  p11-kit-trust-0.25.3-3.el9_5.x86_64  pam-1.5.1-22.el9_5.x86_64  python3-3.9.21-1.el9_5.x86_64  python3-libs-3.9.21-1.el9_5.x86_64 
  shadow-utils-2:4.9-10.el9_5.x86_64

[artis3n]

I cannot reproduce this on a DigitalOcean Droplet running Rocky Linux 9 - no issues with sudo, pam-1.5.1-22.el9_5 is installed, same as in the container. Rest of the packages under the above upgraded list match on the Droplet as well. So some nuance only occurring inside the base image

[artis3n]

Ok, an interesting and baffling data point:

• I cannot reproduce this on Docker with Docker Desktop on an ARM-based MacBook.
• I can reproduce this on Docker with docker-ce on an Ubuntu 24.04 Linux server.
• I can reproduce this on a GH Actions runner, which would likely match the second case.
• I cannot reproduce this on a cloud image of Rocky Linux 9, it is specific to the docker images.

This isn't specific to this image anymore, but something with the base image impacting all centos-like distros (rhel 9, oraclelinux 9, etc.). And differs depending on the underlying host where Docker is running, or an incompatibility with Community Edition vs. Docker Desktop?

[geerlingguy]

Yeah, this is definitely a bit weird... I've been noticing it in my runs on GitHub Actions too, and like you, I don't have the same issue when testing on my Mac with Docker Desktop...

[geerlingguy]

I've added an upstream issue to see if anyone has a clue what's happening: https://github.com/rocky-linux/sig-cloud-instance-images/issues/56

[artis3n]

Ahh awesome, thank you. I posted here after realizing it was some issue in the base image because I didn't want to make an account on https://forums.rockylinux.org/ and couldn't find a base image repo. Now I have it :)

[geerlingguy]

Hmm... same issue in Fedora 40 container in my Docker container:

https://github.com/geerlingguy/ansible-role-docker/actions/runs/13014753313/job/36301031820

  TASK [Gathering Facts] *********************************************************
  fatal: [instance]: FAILED! => {"ansible_facts": {}, "changed": false, "failed_modules": {"ansible.legacy.setup": {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3.12"}, "failed": true, "module_stderr": "sudo: PAM account management error: Authentication service cannot retrieve authentication info\nsudo: a password is required\n", "module_stdout": "", "msg": "MODULE FAILURE: No start of json char found\nSee stdout/stderr for the exact error", "rc": 1}}, "msg": "The following modules failed to execute: ansible.legacy.setup\n"}

The solution there was to just comment out become: true and since Docker is running as root, I guess it all still 'just works' :D

[geerlingguy]

I'll be disabling Rocky Linux 9 (and thus RHEL) CI testing on any of my roles where sudo is required, just to ensure my other tests will keep running. Hopefully we can get this resolved at some point, because assuming the container is in an environment where the user is root inside is not tenable for all circumstances :)

[andtra]

I think this is the issue.

$ podman run -it --rm docker.io/geerlingguy/docker-rockylinux9-ansible:latest bash
[root@fae2d6e73517 /]# sudo -i
sudo: PAM account management error: Authentication service cannot retrieve authentication info
sudo: a password is required
[root@fae2d6e73517 /]# ls -la /etc/shadow
---------- 1 root root 418 Feb 16 02:36 /etc/shadow
[root@fae2d6e73517 /]# chmod 0400 /etc/shadow
[root@fae2d6e73517 /]# ls -la /etc/shadow
-r-------- 1 root root 418 Feb 16 02:36 /etc/shadow
[root@fae2d6e73517 /]# sudo -i
[root@fae2d6e73517 ~]# 

I am a bit unsure why the shadow file don't have read permissions for root.

I think it is releated to some podman specific settings.

[artis3n]

Confirmed that is the problem I see as well (using docker, not specific to podman)

      ansible.builtin.shell:
        cmd: |
          echo ""
          ls -l /etc/shadow
          chmod 0400 /etc/shadow
          ls -l /etc/shadow
          echo ""

[LorenzoBettini]

Confirmed that is the problem I see as well (using docker, not specific to podman)

  ansible.builtin.shell:
    cmd: |
      echo ""
      ls -l /etc/shadow
      chmod 0400 /etc/shadow
      ls -l /etc/shadow
      echo ""

So the explicit chmod fixes the issue?

[stenh0use]

I don't use this image, but have a similar self managed image to this (thanks for the solution). At the end of the docker file adding RUN chmod 0400 /etc/shadow to it fixed the issue for me. At the very least a workaround for now.

[rocodes]

I don't use this project, but I ran into the same issue in another context and had to hunt around for answers too - tldr it could be an apparmor issue:

https://www.tunbury.org/2025/05/13/ubuntu-apparmor/

but instead of disabling the profile: https://github.com/AOSC-Tracking/apparmor/commit/556396a172d09ea032404c7b346f4cf54a949a4e

[dldinternet]

I am not sure how practical this will be for others but I am working around it like this:

    - name: Check if we're running as root
      set_fact:
        is_root: "{{ ansible_user_id == 'root' }}"

    - name: Debugging
      changed_when: false
      register: thing
      ansible.builtin.shell:
        cmd: |
          echo ""
          ls -l /etc/shadow
          ls -l /etc/passwd
          echo "---"
          chmod 0640 /etc/shadow || true
          ls -l /etc/shadow
      become: "{{ not is_root }}"

First, it fixes /etc/shadow permissions if possible, i.e. we became root or are already root Second, we don't become root if we don't have to.