28

Looks like the official docker images for Ubuntu 24.04 ship with a user named ubuntu. While the user name is largely immaterial, the choice of UID/GID 1000 for this default user is a bit disruptive, given it's addition as compared to 22.04. E.g:

--- jammy
+++ noble
@@ -1,4 +1,4 @@
-$ docker run -it --rm ubuntu:22.04 cat /etc/passwd
+$ docker run -it --rm ubuntu:24.04 cat /etc/passwd
 root:x:0:0:root:/root:/bin/bash
 daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
 bin:x:2:2:bin:/bin:/usr/sbin/nologin
@@ -15,6 +15,6 @@
 backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
 list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
 irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
-gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
+_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
 nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
-_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
+ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash

For example, I know a lot of docker related tools, such as the devcontainer CLI, attempt to automatically remap the UID/GID of a container user to match that of the host user, simplifying permissions for bind mounts when sharing files across container and host via volumes. However, most developers already have their user account set to UID/GUI 1000, given that's default when creating an initial host account. Thus, these tools can oddly fail to remap the UID/GID properly during container bringup, leaving developers perplexed when tools regess without having changed any docker container run arguments.

Currently I create a pseudo dever account for any devcontainer tool to latch onto and remap UID/GID via the parameter "remoteUser": "dever", in the devcontainer.json config file.

FROM base as dever

add default user for devcontainer


RUN useradd 

      --create-home 

      --gid root 

      --groups sudo 

      --no-log-init 

      --shell /bin/bash 

      --system 

      dever && 

    echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

Given how only some ubuntu images now ship with a ubuntu user that squats ontop the UID/GID 1000, what alternatives approaches would others recommend when creating an agnostic Dockerfile to remap any normal user UID/GID at bringup? Must I now alway just check for an existing UID of 1000 to generalize across ubuntu base image version?

ruffsl
  • 383

2 Answers2

21

This seems to have been a conscious decision to standardize the use of the non-root "ubuntu" user. A very informative bug report can be found here: https://bugs.launchpad.net/cloud-images/+bug/2005129

In case the link ever disappears, here is the relevant quote:

I'm just going to dump here the workaround to this issue I ended up using, just in case anybody else has the same issue and stumbles across this. I went with this approach because it is (as far as I can see) the smallest possible change to an existing Dockerfile, whereas your suggestions (e.g. changing the username or using usermod) can require deeper changes. (Especially since what my actual Dockerfile is doing, is not directly running useradd, rather launching a complicated install script which ends up eventually calling useradd, and I'd rather not have to hack the install script to do somthing different.)

Just add this one RUN line after the initial FROM:

FROM ubuntu:23.04 RUN userdel -r ubuntu

Now the image is just like the 22.10 one, no "ubuntu" user, no /home/ubuntu directory, and uid 1000 is free for use by another user.

The one drawback, is it prints the annoying but harmless error message "userdel: ubuntu mail spool (/var/mail/ubuntu) not found". If one finds that too annoying, a more elaborate RUN line will stop the error:

FROM ubuntu:23.04 RUN touch /var/mail/ubuntu && chown ubuntu /var/mail/ubuntu && userdel -r ubuntu

Both the touch and chown are required; if you just have the touch without the chown, you'll get the error "userdel: /var/mail/ubuntu not owned by ubuntu, not removing" printed instead.

Simon Kissane, 2023-02-09

All credit should go to the author of that bug report. Hope it helps!

Clemens Sielaff
  • 326
3

As addition to Clemens' answer I post the first solution from the bug #20005129 he linked:

reassign id 1000 to myuser, e

usermod -l myuser ubuntu
Carambakaracho
  • 166