Summary: | <sys-libs/libsemanage-2.4_rc6-r2: After installing SELinux userspace 2.4, login differences occur as long as no migration is done | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sven Vermeulen (RETIRED) <swift> |
Component: | SELinux | Assignee: | Sven Vermeulen (RETIRED) <swift> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | selinux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | selinux-utils | ||
Package list: | Runtime testing required: | --- |
Description
Sven Vermeulen (RETIRED)
2014-11-27 13:52:44 UTC
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 |