shadow-maint / shadow

Upstream shadow tree
Other
303 stars 234 forks source link

useradd --root does not work with glibc version mismatch between roots #692

Open classabbyamp opened 1 year ago

classabbyamp commented 1 year ago

Void Linux's installer uses useradd --root to create the initial non-root user in the installed system, which is mounted at an alternate root. Void's latest iso was generated before we updated from glibc 2.32 to 2.36, so when doing a netinstall, the live system has glibc 2.32 and the alternate root has glibc 2.36. Because of this, it seems useradd can't read /etc/group in the alternate root. There may be other causes for this too, as it has appeared and disappeared over the years, but the glibc mismatch is what I could track it down to in this instance.

Related issues from Void

Workaround

use chroot <dir> useradd instead

Steps to reproduce

  1. download the glibc void iso
  2. boot it (username/password is root/voidlinux)
# xbps-install -R https://repo-fastly.voidlinux.org/current -r /mnt -S base-system
... (press y or enter on the two prompts)
# cat /mnt/etc/group
root:x:0:
bin:x:1:
sys:x:2:
kmem:x:3:
wheel:x:4:
tty:x:5:
tape:x:6:
daemon:x:7:
floppy:x:8:
disk:x:9:
lp:x:10:
dialout:x:11:
audio:x:12:
video:x:13:
utmp:x:14:
adm:x:15:
cdrom:x:16:
optical:x:17:
mail:x:18:
storage:x:19:
scanner:x:20:
network:x:21:
kvm:x:24:
input:x:25:
plugdev:x:26:
usbmon:x:27:
nogroup:x:99:
users:x:100:
xbuilder:x:101:
_uuidd:x:999:
_dhcpcd:x:998:
# useradd --root /mnt --groups users,wheel foo
useradd: group '100' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
useradd: group 'users' does not exist
useradd: group 'wheel' does not exist
# echo $?
6
# cat /mnt/etc/group
(same as before)
# xbps-install -Su xbps
... (press y or enter on the prompt, this will update glibc)
# useradd --root /mnt --groups users,wheel foo
# echo $?
0
# cat /mnt/etc/group
(now lists foo as member of wheel and users)
ahesford commented 1 year ago

I suspect the issue here is calling fgetgrent in libmisc, which on glibc calls fgetgrent_r, which then turns to NSS for dynamic directory queries. After useradd does its chroot, NSS might be trying to load an incompatible NSS module (in Void's case, libnss_files.so.2).

Edit: this conjecture is based only on a thought experiment stepping through the source.