On Thu, Jul 09, 2020 at 05:56:00PM -0400, Judah Milgram wrote: > Ben knows what I'm talking about :)
I will confess to editing directly when I know the distro well (cough cough Slackware) and I'm removing a password outright or changing a group or something. When the distro does funny business with PAM and systemd and whatever the newfangled stuff the kids today are using, I use passwd or usermod, because I've been bitten too many times by sekrit databases [1]. Assuming passwd and usermod still exist, of course. Otherwise, back to vi! > Regarding chroot, I've never actually been clear on one point: if you do > e.g. chroot passwd, does it change root first and then fire up the passwd it > finds in the changed root filesystem? It changes root first and then runs whatever command to tell it. Long drawn out examples follow. chroot /mnt/hd passwd changes root to /mnt/hd, runs passwd, and then exits. chroot /mnt/hd changes root and then runs whatever $SHELL is set to in chroot's own copy of the environment (i.e., whatever $SHELL was when it was called). As I happen to have a chroot lying around: 0 root@farad:~# SHELL=/bin/wibble chroot /usr/local/chroot64 chroot: failed to run command '/bin/wibble': No such file or directory > Or does it find passwd first, then change root ... and if so, how does it > resolve the various libraries, seeing as passwd isn't statically linked and > might be built against different library versions in the changed root fs? And that's why it changes root first. :-) Note that this exact problem is what makes using binfmt_misc + qemu to run 64 bit userland on a 32 bit kernel fail. I've never been able to build a version of qemu that was static enough for chroot /usr/local/chroot64 /usr/bin/qemu-x86_64 /bin/bash (or qemu-system-x86_64) to run, even though I could run them outside of a chroot. (Yes, you can run 64-bit userland on a 32-bit kernel, it's just slow [2].) There's also a lot of fun involving bind mounts and all the pseudo-filesystems most distros want mounted these days, but that's for another email. [1] Slackware 15 is going to use PAM, because apparently KDE 5 Plasma, whatever that is, won't work w/o PAM. (There's an explanation ^W justification from Bob that the PAM code paths are getting more testing than the non-PAM code paths, so this is more secure or something, to which I say "Faugh." Perhaps I should find a polite way to tell Pat my opinion, but I haven't had the round tuits lately.) [2] Originally, I really needed to be able to run 64-bit VMs and I didn't want to reinstall. It worked, but ultimately, I ended up using this to bootstrap from 32-bit to 64-bit without reinstalling. That's also a story for another email. Ben -- Ben Stern This space intentionally left blank. You received this email because you are subscribed to the UM Linux User's Group (UM-LINUX) mailing list. If you would like to unsubscribe from this list, simply send an email to lists...@listserv.umd.edu with the message signoff UM-LINUX in the body.
