When upgrading to 2.4, the SELinux-aware applications (through libselinux/libsemanage) expect information such as the seusers file to be in the new location (/var/lib/selinux/*). However, as long as no migration is done, this file is missing, having those applications return to default behavior. On systems where different mappings are done for users, this might result in users being assigned the wrong SELinux user (potentially locking users out as they are defaulted towards the non-administrative user_r role). Reproducible: Always
I can confirm that this is indeed the case. A potential solution for this is to run the migration from within the ebuilds, but without reloading the policy (the policy loading is what causes the previous attempt to migrate automatically through ebuilds to fail). If we do this as part of the pkg_postinst() phase of libsemanage (which has the migration script) then the seusers file is already migrated. The no-loading part of the migration is only temporarily an issue: - Policy loads will fail due to wrong context (I'll open a bug on this later, it is already confirmed upstream but they have not suggested the right contexts for /var/lib/selinux yet) - Users can easily run "restorecon -R /var/lib/selinux" to fix this and continue This will ensure that users are not locked out of their system. --- libsemanage-2.4_rc6-r1.ebuild 2014-11-27 14:27:37.398724001 +0100 +++ libsemanage-2.4_rc6-r2.ebuild 2014-11-27 14:44:55.736764916 +0100 @@ -103,3 +103,13 @@ python_foreach_impl installation_py fi } + +pkg_postinst() { + # Run the store migration without rebuilds + for POLICY_TYPE in ${POLICY_TYPES} ; do + if [ ! -d "${ROOT}/var/lib/selinux/${POLICY_TYPE}/active" ] ; then + einfo "Migrating store ${POLICY_TYPE} (without policy rebuild)." + /usr/libexec/selinux/semanage_migrate_store -n -s "${POLICY_TYPE}" || die "Failed to migrate store ${POLICY_TYPE}" + fi + done +}
In tree, ~arch
2.4 userland is stable now