On 5 April 2013 08:00, Panu Matilainen <pmati...@laiskiainen.org> wrote: >> rpm preloads NSS libraries prior to chrooting in order to >> fix group lookup in the chroot (when installing in a chroot): >> lib/rpmrc.c- /* Force preloading of dlopen()'ed libraries in case >> we go chrooting */ >> lib/rpmrc.c: (void) gethostbyname("localhost"); >> >> >> However in some cases, this is not enough. >> See https://bugs.mageia.org/show_bug.cgi?id=9326 >> Strace showed that in some case, it tries to load libnss*so >> after chrooting, way too late, resulting in borked installs. > > > Do you have a strace of such a situation still at hand / can you easily > reproduce one?
Yes I can easily reproduce it. > Just interested to see what's going on in such a case, not > that I couldn't imagine things failing in some circumstances: for example if > the system nsswitch.conf specifies hosts to come from a different source > than passwd/group. you know well we use urpmi as our package manager with perl-URPM as the perl binding for rpm. urpmi is used by our installer (drakx) too. Drakx is a little bit like anaconda, a small stage1 loading a full stage2 (a minimal system that will offer to select options and then install the targeted system) that intalls in a chroot (/mnt in drakx vs /mnt/sysimage in anaconda). There's a special case, where we can run our installer directly from a running system, either for debugging or in order to generate a live cd image, unsing a tool named drakx-in-chroot. http://svnweb.mageia.org/soft/drakx/trunk/tools/drakx-in-chroot?view=markup It basically sets up a chroot for the installer, copies a score of files (a cople /dev/ entries, /etc/resolv.conf) and tells the installer it has to run in local mode (no partitionning and the like). Basically we've: running OS -> chroot installer system -> installs in a chroot. When run in graphical (Gtk+) mode, everything worked fine. However, in auto install mode, we found out that group ownership wasn't enforced (see above bug #9326). It was reproductable in text mode too. In the end I found out that as part of it initiliazition gtk+/libx11 was loading some NSS files. When they were not previously loaded, on first translation, rpm installs glibc+setup+filesystem (+a cople other packages), thus having a minimal /etc/group (later packages adding their needed groups when needed if needed). The first time, librpm saw a non root group, it tries to load NSS libraries, which obviously fails since it's now chrooted in the being installed OS (see attached strace diff). In auto install mode, all transactions where some packages use non a root group shows errors (see install.log.diff): +group daemon does not exist - using root +group mail does not exist - using root Obviously this worked previously (up to rpm-4.9 that was used in Mageia2), so either something broke in librpm or some other library was causing NSS libs to be loaded before chrooting. See attached extract diff of two strace "sessions" Here, we can workarounding this either by: - making NSS libs to be loaded from perl before performing the install in a chroot - or by not copying /etc/resolv.conf in the install chroot (which would prevent us to use remote media) - or by patching rpm to really always preload NSS libs But I don't think forcing NSS libs to be loaded is the job of the librpm users, hence the rpm patch. For the record, we do hit rpmReadConfigFiles() before chrooting... >> The following patch makes rpm to really force preloading of >> dlopen()'ed libraries before chrooting >> >> Patches against master & rpm-4.11.x >> >> Please apply. > > > It probably should actually call getpwent() as well for full coverage > against nsswitch.conf variants. And then the gethostbyname() call becomes > unnecessary as we're not interested in hosts, the whole thing is nothing but > a cheap trick that "works" most of the time. > > However I seem to recall glibc caching the passwd and group contents, so if > we force it to read passwd and group before chrooting, it might well end up > using the values from the host system instead of what should go into the > chroot. At the very least I'd think it should call endgrent() (and endpwent) > as well.
strace.diff
Description: Binary data
install.log.diff
Description: Binary data
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint