diskimage-builder/elements/rpm-distro/finalise.d/11-selinux-fixfiles-restore

#!/bin/bash

set -eux
set -o pipefail

if [ -e /etc/selinux/targeted/contexts/files/file_contexts -a -x /usr/sbin/setfiles ]; then
    # Without fixing selinux file labels, sshd will run in the kernel_t domain
    # instead of the sshd_t domain, making ssh connections fail with
    # "Unable to get valid context for <user>" error message
    setfiles /etc/selinux/targeted/contexts/files/file_contexts /
else
    echo "Skipping SELinux relabel, since setfiles is not available."
    echo "Touching /.autorelabel to schedule a relabel when the image boots."
    touch /.autorelabel
fi
Trigger SELinux autorelabel on first boot. This adds about 30 seconds to my local boot time. Fixes bug #1179730 Change-Id: I519bb9289236abd43f8eb784768dcab10e2e5754 2013-05-14 00:03:24 +00:00			`#!/bin/bash`

set -e all the things Using set -e in all of our scripts will prevent some subtle bugs from slipping in, and will allow us to enforce use of set -e with tooling. This change also adds -u and set -o pipefail in the less complex scripts where it is unlikely to cause problems. A follow-up change will enable those options in the complex scripts so that if it breaks something it can be reverted easily. Change-Id: I0ad358ccb98da7277a0ee2e9ce8fda98438675eb 2014-03-29 03:28:22 +00:00			`set -eux`
			`set -o pipefail`
Run fixfiles restore in chroot instead of firstboot. Boot time was 30 seconds shorter in an all-in-one devstack environment. Thanks to Ghe Rivero for a pointer to the solution https://bugzilla.redhat.com/show_bug.cgi?id=208275 Change-Id: I90d0c96d5659326ba67d6119b96d9a4113adf7fe 2013-05-16 02:33:24 +00:00
setfiles consistently Working on host systems without selinux, where the guest image does have selinux, creates a situation where the instance will have about a 1 minute delay on first boot because it must relabel. The previous check for sysfs assumes that the host system has selinux, which is not needed for the guest setfiles to work. Change-Id: Ic186a45991b6d80880ad635e9c80985612f53a05 Closes-bug: 1414200 2015-01-23 23:10:55 +00:00			`if [ -e /etc/selinux/targeted/contexts/files/file_contexts -a -x /usr/sbin/setfiles ]; then`
Skip relabel unless SELinux is enforcing The SELinux relabel of the filesystem is taking almost 2 minutes and isn't needed unless you actually plan to run with SELinux enforcing. Plus, it appears to "leak" out of the chroot, referencing filesystems on partitions that aren't even mounted in the chroot. Note you just can't use getenforce or selinuxenabled here to get the state of SELinux because those commands are not accurate inside a chroot. TBH, a downside of this is that if someone goes to try to enable SELinux in an image where it was built with it not enabled, the file contexts are going to be wrong. So they'd need to relabel themselves at that point. However, this saves me quite a bit of time during image builds, so I thought I'd submit to get other folks opinion on it. Change-Id: I2132060d573fc93cf974f3560fdc651ff8ba38b4 2014-01-23 12:21:58 +00:00			`# Without fixing selinux file labels, sshd will run in the kernel_t domain`
			`# instead of the sshd_t domain, making ssh connections fail with`
			`# "Unable to get valid context for <user>" error message`
			`setfiles /etc/selinux/targeted/contexts/files/file_contexts /`
			`else`
Relabel filesystem if SELinux is available Relabel the filesystem during image builds if SELinux is supported in the kernel of the build machine and userspace tools are available. Otherwise touch /.autorelabel to schedule a relabel the first time the image boots. We relabel when possible because it decreases first boot time. Change-Id: I0bec885d6e5d4f4e1106f3bd2a90ba5f86395b07 Partial-Bug: 1347845 2014-07-21 13:31:55 +00:00			`echo "Skipping SELinux relabel, since setfiles is not available."`
			`echo "Touching /.autorelabel to schedule a relabel when the image boots."`
			`touch /.autorelabel`
Skip relabel unless SELinux is enforcing The SELinux relabel of the filesystem is taking almost 2 minutes and isn't needed unless you actually plan to run with SELinux enforcing. Plus, it appears to "leak" out of the chroot, referencing filesystems on partitions that aren't even mounted in the chroot. Note you just can't use getenforce or selinuxenabled here to get the state of SELinux because those commands are not accurate inside a chroot. TBH, a downside of this is that if someone goes to try to enable SELinux in an image where it was built with it not enabled, the file contexts are going to be wrong. So they'd need to relabel themselves at that point. However, this saves me quite a bit of time during image builds, so I thought I'd submit to get other folks opinion on it. Change-Id: I2132060d573fc93cf974f3560fdc651ff8ba38b4 2014-01-23 12:21:58 +00:00			`fi`