When using e.g. groupadd -R /chroots/test-chroot -f -r test, groupadd enters the chroot jail before just about anything else:
https://github.com/shadow-maint/shadow/blob/master/lib/root_flag.c#L99 invoked by
https://github.com/shadow-maint/shadow/blob/master/lib/root_flag.c#L71 invoked by
https://github.com/shadow-maint/shadow/blob/master/src/groupadd.c#L617
PAM is initialized and queried after the chroot call, so it attempts to load the PAM modules inside the chroot -- which may not be compatible with the PAM library being used (e.g. chroot-ing into a different distro or version with a different version of PAM that is not binary compatible, or chroot-ing into a different architecture [arm chroot on an x86 box, powered by qemu-binfmt], or chrooting into a minimalistic environment that doesn't have PAM at all).
This results in PAM failing (groupadd: PAM: Module is unknown), and in turn the whole groupadd call failing.
(The same happens with various other parts of shadow; just reporting the example of groupadd because that's where I ran into it first).
Possible fixes would be doing the PAM checks before entering the chroot, or disabling PAM if -R is in use (a PAM policy preventing me from adding a group on the host system should not necessarily prevent me from adding groups and users inside a chroot that is more or less unrelated to the host).
When using e.g.
groupadd -R /chroots/test-chroot -f -r test, groupadd enters the chroot jail before just about anything else:https://github.com/shadow-maint/shadow/blob/master/lib/root_flag.c#L99 invoked by
https://github.com/shadow-maint/shadow/blob/master/lib/root_flag.c#L71 invoked by
https://github.com/shadow-maint/shadow/blob/master/src/groupadd.c#L617
PAM is initialized and queried after the chroot call, so it attempts to load the PAM modules inside the chroot -- which may not be compatible with the PAM library being used (e.g. chroot-ing into a different distro or version with a different version of PAM that is not binary compatible, or chroot-ing into a different architecture [arm chroot on an x86 box, powered by qemu-binfmt], or chrooting into a minimalistic environment that doesn't have PAM at all).
This results in PAM failing (
groupadd: PAM: Module is unknown), and in turn the whole groupadd call failing.(The same happens with various other parts of shadow; just reporting the example of groupadd because that's where I ran into it first).
Possible fixes would be doing the PAM checks before entering the chroot, or disabling PAM if
-Ris in use (a PAM policy preventing me from adding a group on the host system should not necessarily prevent me from adding groups and users inside a chroot that is more or less unrelated to the host).