Control: reassign -1 sssd-common 2.8.2-3 Control: affects -1 podman Control: retitle -1 sssd-common" subids nsswitch.conf entry breaks user sub[ug]ids Control: severity -1 serious
Matej Marusak [2023-04-03 14:00 +0000]: > This is easily reproducible by: > - Download newest image, e.g. > https://cloud.debian.org/images/cloud/bullseye/daily/20230403-1339/debian-11-genericcloud-amd64-daily-20230403-1339.qcow2 > - Install podman and sssd-tools and sssd-dbus. It works fine without sssd > - Login as 'admin' user > - podman pull debian > > This command fails with: > ERRO[0004] While applying layer: ApplyLayer stdout: stderr: potentially > insufficient UIDs or GIDs available in user namespace (requested 0:42 for > /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and > run podman-system-migrate: lchown /etc/gshadow: invalid argument exit status 1 > Error: copying system image from manifest list: writing blob: adding layer > with blob > "sha256:3e440a7045683e27f8e2fa04000e0e078d8dfac0c971358ae0f8c65c13321c8e": > ApplyLayer stdout: stderr: potentially insufficient UIDs or GIDs available > in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and > /etc/subgid if configured locally and run podman-system-migrate: lchown > /etc/gshadow: invalid argument exit status 1 Indeed this is a regression in sssd-common. Its postinst now does | # Automatically added by dh_installnss/1.7 | if [ "$1" = "configure" ] && [ -f "${DPKG_ROOT}/etc/nsswitch.conf.nss.${DPKG_MAINTSCRIPT_PACKAGE}-will-install" ] && [ -e "${DPKG_ROOT}/etc/nsswitch.conf" ] ; then | if ! grep -q -E -e '^subid:[^#]*\s(sss)(\s|#|$)' "${DPKG_ROOT}/etc/nsswitch.conf" ; then | # Installing subid/sss from sssd-common in position last | sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e '/^subid:\s[^#]*$/ s/$/ sss/' -e '/^subid:\s.*#/ s/#/ sss #/' | fi | rm "${DPKG_ROOT}/etc/nsswitch.conf.nss.${DPKG_MAINTSCRIPT_PACKAGE}-will-install" | fi Which the previous version didn't do. This causes this entry in /etc/nsswitch.conf: subid: sss ... which is broken: # getsubids admin Error fetching ranges It works with "subuid: files sss" or with dropping that line altogether, so that it goes back to reading /etc/sub[ug]id: # getsubids admin 0: admin 100000 65536 Either this postinst snippet forgets to add "files" or it forgets to systemctl enable whichever service is supposed to respond to the "sss" service for "subid". Raising to RC, as this breaks unrelated software, and this change happened during freeze already. Thanks, Martin