Hide Forgot
Description of problem: When a container issues a reboot or telinit command regardless of privileged flag settings specifically when --pid=host is provided, the result will always meet a chroot error. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Atomic Host release 7.2 open-vm-tools-9.10.2-4.el7.x86_64 How reproducible: /usr/bin/docker run --privileged -v /proc/:/hostproc/ -v /sys/fs/cgroup:/sys/fs/cgroup -v /var/log:/var/log -v /run/systemd:/run/systemd -v /sysroot:/sysroot -v=/var/lib/sss/pipes/:/var/lib/sss/pipes/:rw -v /etc/passwd:/etc/passwd -v /etc/shadow:/etc/shadow -v /tmp:/tmp:rw -v /etc/sysconfig:/etc/sysconfig:rw -v /etc/resolv.conf:/etc/resolv.conf:rw -v /etc/nsswitch.conf:/etc/nsswitch.conf:rw -v /etc/hosts:/etc/hosts:rw -v /etc/hostname:/etc/hostname:rw --env container=docker --net=host --pid=host openvmtools with the following Dockerfile: FROM registry.access.redhat.com/rhel7 RUN yum -y --disablerepo=\* --enablerepo=rhel-7-server-rpms install yum-utils && \ yum-config-manager --disable \* && \ yum-config-manager --enable rhel-7-server-rpms && \ yum clean all RUN yum -y install file open-vm-tools perl open-vm-tools-deploypkg net-tools && \ yum clean all CMD /usr/bin/vmtoolsd Steps to Reproduce: 1. Attempt to customize a VMware virtual machine running Atomic OS 7.2 2. Use systemd unit file to automate the execution of the container for customization 3. The final step of the customization issues a telinit 0 Actual results: Running in chroot, ignoring request. Expected results: Rebooted VM with properly applied networking configuration. Additional info: Please refer to the following bugzilla for more information concerning the hows and whys - https://bugzilla.redhat.com/show_bug.cgi?id=1166465 I dug into the systemd a little and here are the excerpts in question: line 8050 https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c if (arg_action != ACTION_SYSTEMCTL && running_in_chroot() > 0) { log_info("Running in chroot, ignoring request."); r = 0; goto finish; } line 487 https://github.com/systemd/systemd/blob/master/src/basic/virt.c int running_in_chroot(void) { int ret; ret = files_same("/proc/1/root", "/"); if (ret < 0) return ret; return ret == 0; }
As for the container check, would it make sense to check for /.dockerenv or /.dockerinit in the running_in_chroot function?
Only if you want to only ever run under docker. Why would you want to check if you are running in a container?
Looking at systemd/systemctl code it looks like it is checking if the processes is running in a container and then blocking certain access. We want to allow processes inside of a privileged contianer to interact with systemd on the host. There needs to be a way to bypass this check. On an atomic host there is no way to ship software other then a container, and we need to ship software that manages systemd.
We disallow that because in general case talking to PID 1 from chroot is not what you want, e.g. PID 1 operates on different set of unit files than you can see in the chroot environment. However, in cases when you know what you are doing we should allow people to shoot them self into the foot (doesn't apply here because you just want to reboot). I discussed this issue with Lennart on systemd.conf and he proposed that we add new environment variable (SYSTEMCTL_ALLOW_CHROOT or so) and if set chroot check will be skipped.
That works for me. We need this in Fedora and RHEL though.
Tentative devel_ack for 7.4. But it needs to get to upstream first.
Lukáš any chance of getting this prior to 7.4?
I think we should be able the get it into upstream soon, the patch is trivial although pretty "annoying", all systemd binaries use the same function for parsing environment variables and systemctl will need something extra. But tomorrow is my Upstream Friday so I will try to come with pull request. And then we can pack it to the next z-stream, probably batch 1, if everything goes well.
https://github.com/systemd/systemd/pull/4374
Awesome! Thanks so much Lukáš!
https://github.com/systemd/systemd/commit/08a28eeca70eeefb55af61191b63e4c938daca73
https://github.com/lnykryn/systemd-rhel/pull/62
fix pushed to staging -> https://github.com/lnykryn/systemd-rhel/commit/f3750cbfd21b2e5f6f46077082f60e3a74ee4807 -> post
Tested and works great! Thanks again!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2297