-
Notifications
You must be signed in to change notification settings - Fork 204
Description
When adding a configured user to an image as performed in https://github.com/chainguard-dev/apko/blob/main/pkg/build/accounts.go , apko creates the user configured in the passwd format to have its password entry stored in /etc/shadow, but does not create the corresponding entry (with the entry locked) in the shadow file itself.
This can be seen for example in the wolfi-base image, which the image is configured to add a nonroot user:
$ docker run -i --rm -t --entrypoint sh cgr.dev/chainguard/wolfi-base:latest
/ # grep nonroot /etc/passwd
nonroot:x:65532:65532:Account created by apko:/home/nonroot:/bin/sh
/ # grep nonroot /etc/shadow
/ #
If installed, the shadow package's pwck will complain and prompt to add the missing entry:
/ # apk add shadow
fetch https://apk.cgr.dev/chainguard/x86_64/APKINDEX.tar.gz
(1/24) Installing py3-pip-wheel (25.3-r2)
(2/24) Installing libbz2-1 (1.0.8-r21)
(3/24) Installing libexpat1 (2.7.3-r0)
(4/24) Installing libffi (3.5.2-r1)
(5/24) Installing gdbm (1.26-r1)
(6/24) Installing xz (5.8.1-r6)
(7/24) Installing libstdc++ (15.2.0-r6)
(8/24) Installing mpdecimal (4.0.1-r3)
(9/24) Installing ncurses-terminfo-base (6.5_p20251025-r1)
(10/24) Installing ncurses (6.5_p20251025-r1)
(11/24) Installing readline (8.3-r1)
(12/24) Installing sqlite-libs (3.51.1-r0)
(13/24) Installing libuuid (2.41.2-r2)
(14/24) Installing python-3.13-base (3.13.10-r0)
(15/24) Installing libcap-ng (0.8.5-r4)
(16/24) Installing audit (4.0.3-r1)
(17/24) Installing libmd (1.1.0-r5)
(18/24) Installing libbsd (0.12.2-r3)
(19/24) Installing libpcre2-8-0 (10.47-r0)
(20/24) Installing libsepol (3.9-r1)
(21/24) Installing libselinux (3.9-r1)
(22/24) Installing linux-pam (1.7.1-r3)
(23/24) Installing libsemanage (3.9-r1)
(24/24) Installing shadow (4.18.0-r6)
Executing busybox-1.37.0-r50.trigger
OK: 75 MiB in 39 packages
/ # pwck
user 'shutdown': program '/sbin/shutdown' does not exist
user 'halt': program '/sbin/halt' does not exist
no matching password file entry in /etc/shadow
add user 'nonroot' in /etc/shadow?
From the shadow-utils version of the passwd(5) man page:
If the password field is a lower-case “x”, then the encrypted
password is actually stored in the shadow(5) file instead;
there must be a corresponding line in the /etc/shadow file,
or else the user account is invalid.
While the standard linux-pam based utilities seem to handle this okay (the non-root user is not permitted to log in), other tools that need to interact with the password database may not handle this correctly.