kubernetes-ingress: whoami: cannot find name for user ID 101 after ssh-ing in pod container

Describe the bug

when running command whoami or ‘cat /etc/passwd’ after exec into NIC (v3.2.0 >= plus only) pod:

    $ whoami
          whoami: cannot find name for user ID 101

    $ cat /etc/passwd
          root:x:0:0:root:/root:/bin/bash
          [...]
          nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
          nginx:x:999:999:nginx user:/nonexistent:/usr/sbin/nologin

when running command whoami or ‘cat /etc/passwd’ after exec into NIC (v3.2.0 < plus only) pod:

     $ whoami
            nginx
            
      $ cat /etc/passwd
            root:x:0:0:root:/root:/bin/bash
            [...]
            _apt:x:100:65534::/nonexistent:/usr/sbin/nologin
            nginx:x:101:101:nginx user,,,:/nonexistent:/bin/false

To Reproduce

Install an IC instance with plus images for v3.2.0+ and ssh into pod container and run above commands.

About this issue

Original URL
State: closed
Created 9 months ago
Comments: 17 (12 by maintainers)

Most upvoted comments

Sounds like a plan.

brianehlert on Oct 25, 2023

I am an old systems person and not a fan of hard coding anything. It always returns to bite you in the end. Lets give a chance for review to happen, since we have wider impacts than previously known around this issue. It was unknown until today that there was any break associated with this.

brianehlert on Oct 25, 2023

Oh of course. I am just highlighting that reverting the packaging change and applying #4540 has its own benefits of re-using upstream an implementation. But doing explicit user/group creation in Dockerfile here is a way forward too! (The user creation doesn’t slow anything down. I fully agree it’s negligible from a size and speed point of view.)

On a different topic though, it is interesting to me how this was not picked up in test scenarios, if app-protect is broken. I am an OSS user, so I am not aware of the failure scenario here. Just strange that CI did not pick up issues.

sigv on Oct 25, 2023

I think we should stick to manually setting the uid and gid for the user like in the OSS images and in ubi-plus https://github.com/nginxinc/kubernetes-ingress/blob/b9afaa7c4b6f8d4583f2b7cfbb63fc2afd98e308/build/Dockerfile#L156-L157

lucacome on Oct 25, 2023

Explicit is not always better. It’s more about alignment, compromise and accepting risks. In the Debian Plus scenario, there are no notable drawbacks to creating the user early (before installing the package) – it’s just a bit longer command for the builder.

At the same time, for Debian OSS and Alpine OSS images (built from nginxinc/docker-nginx) I do not think you want to add logic to recreate user, and can instead accept the risk that upstream needs to keep the UID as 101 (ref: debian and alpine-slim).

sigv on Oct 25, 2023

thanks @sigv, I’ll have a look at the changes.

vepatel on Oct 19, 2023

I opened #4540 with my proposed change to FIRST_SYSTEM_UID.

However, please check how the Nginx Plus Debian package creates the user, as you want adduser for creating the lowest UID.

I would suggest to change packaging for the Debian package, switching back to adduser, resulting in UID 100. If that is observed, then it signals my PR is relevant for bumping UID 100 up to 101.

sigv on Oct 18, 2023