Since selinux-policy-40.12-1, the “/var/run = /run” equivalency is inverted, so entries for /var/run are ignored. There is an rpm scriptlet which creates a new module with just /run entries, but it may not work in all cases.
Regarding /run/cryptsetup, I believe it is used not only for systemd-homed.
Ooookeey… New issue 
but first things first:
/usr/lib/systemd/systemd-homed , /usr/lib/systemd/systemd-homework, /usr/lib/systemd/system/systemd-homed.service, /usr/lib/systemd/system/systemd-homed-activate.service and /var/lib/systemd/home are labeled properly - authselect with systemd-homed - bootc variant, additions to the image made via OCI layering:NAME="Fedora Linux"
VERSION="40.20240911.0 (Silverblue)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40.20240911.0 (Silverblue)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://silverblue.fedoraproject.org"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-silverblue/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://github.com/fedora-silverblue/issue-tracker/issues"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="Silverblue"
VARIANT_ID=silverblue
OSTREE_VERSION='40.20240911.0'
The fun part of it is that if I try creating a user with homectl, I get the following errors:
systemd-homed: Failed to open key file for writing: Permission denied
AVC avc: denied { add_name } for pid=4538 comm="systemd-homed" name=".#local.publicfd1e6ccb986ce35d" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_homed_library_dir_t:s0 tclass=dir permissive=0
ls -alZ /var/lib/systemd/ gives this:
drwxr-xr-x. 2 root root system_u:object_r:systemd_homed_library_dir_t:s0 4096 Sep 12 11:15 home
And this is from Fedora Workstation 40, where it works beautifully:
drwxr-xr-x. 2 root root system_u:object_r:systemd_homed_library_dir_t:s0 4096 2024-09-11 22:36 home
ls -alZ /usr/lib/systemd:
-rwxr-xr-x. 1 root root system_u:object_r:systemd_homed_exec_t:s0 236192 Sep 12 20:52 systemd-homed
-rwxr-xr-x. 1 root root system_u:object_r:systemd_homework_exec_t:s0 239296 Sep 12 20:52 systemd-homework
ls -alZ /usr/lib/systemd/system:
-rw-r--r--. 1 root root system_u:object_r:systemd_homed_unit_file_t:s0 645 Sep 12 20:52 systemd-homed-activate.service
-rw-r--r--. 1 root root system_u:object_r:systemd_homed_unit_file_t:s0 1374 Sep 12 20:52 systemd-homed.service
After long tinkering and experimenting I see no obvious cause for homectl not to create homed-managed user, but clearly it is something missing/wrong.
But maybe someone of you can see/know what I don’t 
?
The breakdown: 
Command systemd-homed, labeled scontext=system_u:system_r:init_t:s0, is requesting to add name to a tclass=dir “directory”, which is labeled tcontext=system_u:object_r:systemd_homed_library_dir_t:s0
systemd-homed is not labeled correctly. It still has it’s default label, according to selinux, hence why it is denied.
Thanks @richiedaze for explaining this, it all makes sense. I just was confused seeing proper SELinux labels as ls output, but being unable to create user. Interestingly, if SELinux labels are applied after remounting /usr rw, then homectl creates new users with no problems. But if SELinux contexts are added when files are bind mounted as per ublue example , then systemd-homed fails as if it has default, not fixed SELinux context although ls shows otherwise. Not sure if this ublue’s approach can be applied in this case, thus reverting back to /usr remount rw until there is better solution…
It seems that ublue relabels the mount, and not the actual file. It’s kind of like how I relabeled the home mount in the homectl create command to have the proper labels for the LUKS encrypted home directory.
If you feel that leaving the /usr mount rw is risky, do your edits, then remount it back to read only after your done.
Thank you for the clarification on the /run /var/run issue. I can confirm that /var/run is ignored even though it’s still visible on the policy fcontext.
The reason I labeled /run/cryptsetup is because when I initially created this policy around f32, this directory was not created on boot and was created by the homectl create command. Since this is not the case anymore, I have removed the label from the upstream policy PR and adjusted the rules to comply with the change.
This is great! Thanks so much for your work!
As well as a restorecon under homectl with $NEW_USER : [RFC] Support systemd-homed by maage · Pull Request #939 · fedora-selinux/selinux-policy · GitHub