Description of problem: `man systemd-nspawn` describes how to to create a Fedora OS container using `dnf`, and boot it. This isn't any use on it's own though; you also need to set a root password, so you can actually log in. These more useful instructions were provided in the blog post http://0pointer.net/blog/systemd-for-administrators-part-xxi.html But, attempting to set the root password is currently failing with a SELinux denial. This is a documentation bug in systemd-nspawn :-P ... maybe it can be fixed for real, the problem is I don't really know what causes it. http://unix.stackexchange.com/questions/308687/systemd-nspawn-os-container-is-unusable-because-i-cant-set-the-root-password/308688#308688 The best explanation I have for the SELinux denial are the labels: $ ls -Z fedora-24/etc/passwd unconfined_u:object_r:etc_t:s0 fedora-24/etc/passwd $ ls -Z fedora-24/bin/passwd system_u:object_r:passwd_exec_t:s0 fedora-24/bin/passwd compared to the host system system: $ ls -Z /etc/passwd system_u:object_r:passwd_file_t:s0 /etc/passwd $ ls -Z /usr/bin/passwd system_u:object_r:passwd_exec_t:s0 /usr/bin/passwd Version-Release number of selected component (if applicable): systemd-229-13.fc24.x86_64 dnf-1.1.10-1.fc24.noarch rpm-4.13.0-0.rc1.27.fc24.x86_64 libsemanage-2.5-5.fc24.x86_64 How reproducible: always Steps to Reproduce: 1. sudo dnf -y --releasever=24 --installroot=$HOME/fedora-24 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install systemd passwd dnf fedora-release vim-minimal 2. sudo systemd-nspawn -D fedora-24 3. passwd Actual results: passwd fails with "Authentication token manipulation error", and the host desktop pops up an AVC error Expected results: Instructions in systemd-nspawn man page should be sufficient to boot *and log in to* an OS container. That was the whole point of systemd-nspawn :). If it doesn't work anymore - if it's only useful as a convenient chroot, without booting a systemd instance in the container - the documentation should be fixed to avoid wasting users time.
The /etc/passwd should probably not be mislabeled after installation. From the systemd point of view, we could probably improve the man page with something like "If you happen to be using selinux, you may have to run restorecon on the installed root...", but that would likely be a downstream patch. The same message could be sprinkled across man pages in the entire distro... Plus, what about apparmor users? In my opinion, it's just an example and if you are savvy enough to know what those commands mean, you should know that you're running selinux a relabel the directory afterwards.
I noticed something suggestive of a suspicion I had . `mycontainer/etc/passwd-` (which is the backup copy) _was_ labeled as `passwd_file_t`. So what must happen is `dnf --installroot` _does_ labels the installed file. But it looks as if one (and only one) of the rpm scripts runs `useradd`. The environment they run in is not selinux-aware, so the modified `/etc/passwd` is created without a label. Just like containers run with libselinux disabled. I think I was wrong to title this "no longer", i.e. a regression. I remembered using systemd-nspawn on F23. However reproducing this on F23, it still shows a label on `mycontainer/bin/passwd`. It doesn't rule out the original blog instructions were correct. I don't know if the original `yum` with `--installroot` applied labels. (I guess what I see with dnf is convenient & efficient for installing an uncontained OS). > "If you happen to be using selinux, you may have to run restorecon on the installed root..." The systemd-nspawn instructions for Fedora already assume dnf and fedora-repos are installed. Surely SELinux should be the default assumption in that case. > what about apparmor users? Apparmor users won't be affected. It checks paths at runtime - there are no labels to get mismatched.
Is the passwd file the only mislabeled file? I never had to run restorecon in setup package before - and nothing changed recently. IOW I'm not sure this is an issue with setup package...
restorecon doesn't seem to have any useful effect ( sudo restorecon -Rv /var/tmp/fedora-24-fronly/etc/passwd* restorecon: Warning no default label for /var/tmp/fedora-24-fronly/etc/passwd restorecon: Warning no default label for /var/tmp/fedora-24-fronly/etc/passwd- ) But 'setenforce 0' on the host fixes the problem, i.e. allows /bin/passwd to work in the container.
`/etc/passwd` is the only problem file I noticed. I booted the container without any SELinux popups, it was only when running `passwd` I had a problem. I don't know what issue is being suggested with the setup package either. I notice the manpage for `setfiles` says it is usually "run as part of the SELinux installation process" to relabel files. My `dnf --installroot` didn't specify anything related to SELinux, and setfiles/restorecon weren't installed. Nor any SELinux policy... ...if anything, doesn't it seem strange that `dnf --installroot` is setting labels? Labels come from SELinux policies, right, so they're actually not coming from the packages. dnf must be applying the host policy inside the target, which is just bogus. I tried yum-deprecated, but it does exactly the same. *shrug* Zbigniew: you're right, `restorecon -Rv /var/tmp/x` apparently doesn't work. `restorecon -Rv $HOME/x` does work. /not a SELinux expert.
You need to run the restorecon based on the containers paths not on the hosts. restorecon does not take an alternate root path but setfiles does. Something like setfiles -v /etc/selinux/targeted/context/file_context -r /var/tmp/fedora-24-fronly /var/tmp/fedora-24-fronly
Something created the /etc/passwd file with the wrong label, based on its parent label. I actually prefer to use containers with a single label and not treat them like VMs. I would label all of the content with something like unconfined_u:object_r:svirt_sandbox_file_t:s0:c1,c2 and then launch the container with unconfined_u:unconfined_r:svirt_lxc_net_t:s0:c1:c2 This would give the container isolation from the host. Now if you launched another container you would change the s0:c1,c2 to s0:c2,c3 and your containers would be isolated from each other. If you use the same labeling inside of the container as outside and run them as unconfined_t, then you are not getting any isolation from SELinux and you can get these types of transition and labeling problems. Treat containers as microservices not VM's
systemd-nspawn is designed and documented for OS containers. Also as "not suitable for fully secure container setups", so I'm not aiming for that :). I agree sensible people are using the single-label approach, because SELinux isn't namespaced, and the suggested `setfiles` command is not likely to do what anyone wants. I wanted an OS container to develop & test some software; again, what systemd-nspawn is designed for. "Similar to chroot", and it sorts out things like `/proc` for me. Other distributions include other tools - schroot, lxc. lxd. I still think it's a bug in the systemd-nspawn _instructions_, that the instructions don't work because of SELinux. I deliberately used `restorecon` to clear the labels back to the _host_ location's default. I'm sorry it's confusing, I should have been more explicit. I did look for instructions on clearing labels, but the other method I found seemed to assume selinux was already disabled. And using restorecon to apply the system policy is a failsafe way to make sure a subsequent system relabel won't break my setup (barring policy changes).
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.