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
This commit is contained in:
James Slagle 2014-01-23 07:21:58 -05:00
parent b12c28dde8
commit ea257c96d9

View File

@ -2,11 +2,20 @@
set -x set -x
# Without fixing selinux file labels, sshd will run in the kernel_t domain CONFIGURED_SELINUX=$(grep ^SELINUX= /etc/selinux/config | awk -F = '{print $2}')
# instead of the sshd_t domain, making ssh connections fail with
# "Unable to get valid context for <user>" error message if [ "$CONFIGURED_SELINUX" == "enforcing" ]; then
setfiles /etc/selinux/targeted/contexts/files/file_contexts / # Without fixing selinux file labels, sshd will run in the kernel_t domain
FIXFILES_LOG=$(mktemp) # instead of the sshd_t domain, making ssh connections fail with
fixfiles -l $FIXFILES_LOG restore # "Unable to get valid context for <user>" error message
cat $FIXFILES_LOG setfiles /etc/selinux/targeted/contexts/files/file_contexts /
rm $FIXFILES_LOG FIXFILES_LOG=$(mktemp)
fixfiles -l $FIXFILES_LOG restore
cat $FIXFILES_LOG
rm $FIXFILES_LOG
else
echo "Skipping SELinux relabel, since it is not Enforcing."
echo "To relabel once the image is running, use:"
echo "setfiles /etc/selinux/targeted/contexts/files/file_contexts /"
echo "fixfiles restore"
fi