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

#!/bin/bash

if [ ${DIB_DEBUG_TRACE:-1} -gt 0 ]; then
    set -x
fi
set -eu
set -o pipefail
SETFILES=$(which setfiles)
if [ -e /etc/selinux/targeted/contexts/files/file_contexts -a -x "${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`

Standarise tracing for scripts There is a wide variety of tracing options through the various shell scripts. Some use "set -eux", others explicity set xtrace and others do nothing. There is a "-x" option to bin/disk-image-create but it doesn't flow down to the many scripts it calls. This adds a global integer variable set by disk-image-create DIB_DEBUG_TRACE. All scripts have a stanza added to detect this and turn on tracing. Any other tracing methods are rolled into this. So the standard header is --- if [ "${DIB_DEBUG_TRACE:-0}" -gt 0 ]; then set -x fi set -eu set -o pipefail --- Multiple -x options can be specified to dib-create-image, which increases the value of DIB_DEBUG_TRACE. If script authors feel their script should only trace at higher levels, they should modify the "-gt" value. If they feel it should trace by default, they can modify the default value also. Changes to pachset 16 : scripts which currently trace themselves by default have retained this behaviour with DIB_DEBUG_TRACE defaulting to "1". This was done by running [1] on patch set 15. See the thread beginning at [2] dib-lint is also updated to look for the variable being matched. [1] https://gist.github.com/ianw/71bbda9e6acc74ccd0fd [2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/051575.html Change-Id: I6c5a962260741dcf6f89da9a33b96372a719b7b0 2014-09-04 04:56:29 +00:00			`if [ ${DIB_DEBUG_TRACE:-1} -gt 0 ]; then`
			`set -x`
			`fi`
			`set -eu`
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 -o pipefail`
Use environment setfiles Hard coded path fails on Distros (such as el6) with setfiles bin in different places, for example, rhel6 has this in /sbin/setfiles Change-Id: I7aff9cdadd9aed9cfc806a1010acbf36b7b6d0e7 2015-04-16 18:47:19 +00:00			`SETFILES=$(which setfiles)`
			`if [ -e /etc/selinux/targeted/contexts/files/file_contexts -a -x "${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`