2

I chrooted into my testsystem with

mount /dev/vg0/vm01.buster-test-disk /media/vm01.buster-test-disk/
mount -t proc none /media/vm01.buster-test-disk/proc
mount --bind /dev /media/vm01.buster-test-disk/dev
mount -t sysfs sysfs /media/vm01.buster-test-disk/sys
chroot /media/vm01.buster-test-disk/ /bin/bash

adapted the Hostname and exit

hostname buster-test
echo buster-test > /etc/hostname
echo "127.0.0.1 buster-test" >> /etc/hosts
exit

unmount

umount /media/vm01.buster-test-disk/proc
umount /media/vm01.buster-test-disk/dev
umount /media/vm01.buster-test-disk/sys
umount -l /media/vm01.buster-test-disk

Problem

now the host has its hostname set to buster-test even if I login in in another shell

Why did the hostname change? And are there other things that could change outside the chroot, when doing stuff inside?

rubo77
  • 28,966

3 Answers3

6

Running hostname buster-test changed the hostname in the running kernel (on Linux, in the current UTS namespace). chroot on its own doesn’t control that at all, so the hostname change was visible outside too.

When you use chroot, you’re only limiting access to a portion of the file system; anything which isn’t managed in a file system won’t be constrained to the “environment” created by chroot. This includes network setup, the date and time, user permissions, etc. To constrain such changes, you need to use namespaces (or similar technologies on non-Linux systems); on Linux, you can isolate processes by running them with unshare.

Stephen Kitt
  • 434,908
  • so I guess echo buster-test > /etc/hostname would have been enough – rubo77 May 25 '20 at 10:27
  • Probably not, you need something to act upon that. – Stephen Kitt May 25 '20 at 10:31
  • I thought the setting in /etc/hostname would be used after a reboot? – rubo77 May 25 '20 at 12:35
  • 2
    Oh, right, you don’t need it to be used now, you’re trying to store it in the target disk so that it will be used in your test system, is that correct? Then yes, it will be read during boot in the test system, so writing /etc/hostname in the chroot would be sufficient. In fact you don’t even need a chroot here, you can write the two files in etc in your mounted file system. – Stephen Kitt May 25 '20 at 12:37
  • 2
    unshare --uts chroot /media/vm01.buster-test-disk/ Blocks changes to hostname and domainname from affecting the rest of the system. – Cameron Tacklind Jul 18 '21 at 21:30
1

The hostname is the nodename part of the uname(2)system call and the related data resides inside the kernel.

Unless you have a kernel that is able to handle something like zones with own kernel data structures, a simple chroot does not help.

schily
  • 19,173
1

systemd-nspawn can be used instead of chroot to get a containerized chroot. Containers have better isolation between host and guest systems than chroot does.

systemd-nspawn may be used to run a command or OS in a light-weight namespace container. In many ways it is similar to chroot(1), but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name.

Cameron Tacklind
  • 254