[nSLUG] Using chroot to modify mounted "guest" OSes (Was: lost user access in most distros)

Ben Armstrong synrg at sanctuary.nslug.ns.ca
Wed Sep 20 08:35:04 ADT 2006

rejean chamberland wrote:
> In most distros the user is now 501 and the group is sometimes 500 or root. To be more specific I would have to go back in each distro.
When ls reports the number of a user or group instead of its name, it is
because that user doesn't exist on the system's own /etc/passwd or
/etc/group.  Each system has its own copy of these files and the uid &
gid in each for "rejean" don't necessarily match.
> No one else touches my Linux box physically but someone suggested a rootkill. ( or rootkit). All I know as I said partly at the beginning is that I copied a file from PCLinuxOS to the other distros using "mount /dev/<whatever> /mnt/<whatever> and sometimes I had to do a "chown -R rejean /mnt<whatever>/home/rejean/".

Well, that's your problem.  When you mount another distribution's
partition and copy materials to it, you are using the /etc/passwd and
/etc/group of whatever system you're currently booted into.  So you may
be "rejean:rejean" (uid=500, gid=500) on distribution A, "rejean:rejean"
(uid=1000, gid=1000) on distribution B, and "rejean:rejean" (uid=1000,
gid=1000) on distribution C.  So, supposing you're booted into "A" and
have "B" and "C" mounted as described above.  When you chown -R
rejean:rejean on the materials copied onto B and C, and then boot into B
and C, neither system will have the correct uid & gid.  They'll each
report 500:500 instead of "rejean:rejean".

Fortunately, there's an easy way to temporarily "become" system B and
C.  It is called "chroot".  This is a utility that must be run as the
superuser because it uses the privileged chroot() system call to do its
work.  Thus, as root:

mkdir /mnt/B
mkdir /mnt/C
mnt /dev/hda1 /mnt/B
mnt /dev/hda2 /mnt/C
cp -a /home/rejean/stuff /mnt/B/home/rejean/
cp -a /home/rejean/stuff /mnt/C/home/rejean/
chroot /mnt/B
chown -R rejean:rejean /home/rejean/stuff
chroot /mnt/C
chown -R rejean:rejean /home/rejean/stuff

As soon as you type "chroot /mnt/B" you are now in a new shell in which
"/mnt/B" is the new "/".  All filepaths are now relative to that new
filesystem root.  That means any command you run is loaded from your "B"
system, and all filepaths you refer to need to be specified exactly as
if you were booted in the "B" system.  When you type "exit" you leave
this shell and return to the unchrooted shell of your host system.

Note #1:

Take care to remember when you're in and when you're out of a chroot
shell, since if you forget, you can make mistakes that will damage on or
the other systems (or at least cause you a great deal of confusion later
-- trust me, I know this from experience :)

Note #2:

When you're inside a chroot, you *only* have access to files inside the
chroot.  For this reason, you'll often hear the term "chroot jail"
applied to a chroot.  This is an environment set up using chroot to
provide users with a "virtual system" in which they can make changes to
the virtual system but not damage the host.  (There are limits to how
well chroot jails can isolate the user from the host -- search the web
and read up on it if you're interested.)

Note #3:

It's important to remember that even though from the filesystem point of
view it looks like you're logged into system B, it's all a deception. 
Inside a chroot, you don't (at least initially) have any processes
running other than the chrooted shell itself.  You're still running the
kernel of the host system, you don't yet have access to the /proc
virtual filesystem or the /sys virtual filesystem, and any /dev nodes
that are dynamically created (e.g. via udev) won't be available to you. 
Nevertheless, with a bit of care, it is possible to perform mounts,
create necessary device files to interact with devices (e.g. sound card)
and start processes within the chroot and do many things with the
mounted "guest" OS as if you were booted into it.  It is even possible
to install and upgrade packages inside a chroot.  But that's a topic
beyond the scope of my little mini-chroot tutorial here and besides is
widely documented out there on the web.



More information about the nSLUG mailing list