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
Hello!
I am considering systemd-homed for home folder encryption on a fresh install of Fedora 42. I am wondering what part of the initial post still applies or if anything needs to be changed.
Also, I see mentions of FIDO2 and Yubikeys. How should I alter the user creation command to take advantage of it, and would this be for decryption or authentication or both?
Finally, could I use a fingerprint reader for either decryption or authentication or both? If so, what commands would I use for that?
Thank you very much!
You need to install with a regular user, and create a new user through the homectl command.
Since systemd-homed is a daemon, not 100% perfected yet, I suggest you keep the install-time user under a different name like admin or whatever.
man homectl will show you all the required options, although a bit verbose still readable (Not like the archwiki or whatever).
There is one minor caveat; You need to run the following commands before you login:
USERNAM=username # Replace "username" with your actual username
sudo homectl with "${USERNAM}" -- restorecon -vFR "/home/${USERNAM}"
Thanks, I’ll keep this in mind.
I followed the instructions in the very first post and I was able to create my user. When I logged in the first time, I got sent back to the GDM login screen and when I tried to login back it said I had another session running but would not let me terminate it. Anyways, after rebooting, I was able to login.
When I created my user, I used the following options:
--fido2-device=auto --fido2-with-client-pin=yes
so that I could use my Yubikey. I was hoping that I could use either a password or my Yubikey+PIN to log in; however, the options above result in making both the password AND the Yubiey+PIN required. I found this page:
which suggests changing PAM configuration. However, my PAM file says it was created by authselect and should not be modified directly.
So, the question is: how can I use authselect to change requirements so that I can login (authenticate and decrypt my home folder) using only a password or Yubikey+PIN, but not both?
Also, if I wanted to throw a fingerprint into the mix, what I could use that for (authentication? login? decryption?) and how would I go about setting it up?
Thanks!
It just switches 2 lines’ order. No issue. If you are using kinoite/silverblue atomic de variants, just do it.
If you use traditional fedora, `sudo cp /etc/pam.d/system-auth{,.OLD~}` just in case.
I have bricked my OS many times playing with different combinations on PAM stacks. Authselect is the best way to create a custom profile with your combination
Check for your current profile:
sudo authselect current
An example profile will be displayed
Profile ID: local
Enabled features:
- with-systemd-homed
- with-silent-lastlog
Create a copy of this profile to edit
NAME what you want to name this new profile
local since it is the current profile
sudo authselect create-profile NAME --base-on=local
Editing your new profile
/etc/authselect/custom/NAME/*Once your done editing your profile
Activate the profile
sudo authselect select NAME
Log out user, log back in to check if your edits work correctly. If eveything is ok, then nothing else is needed.
If you brick your device, you can change the profile back to default from your DM, GRUB, or user terminal.
sudo authselect select NAME
Check out
Thank you @pramodvu1502 and @richiedaze!
I played around with this all day yesterday. I tried modifying my authselect profile; indeed I locked myself out of my account, and I could not recover it.
I reinstalled Fedora, and this time I created a homed user without Fido2. I still had some issues. One: I got asked for password twice upon every login. Two: a bunch of stuff did not work, like the terminal (I forgot to write down the error message) and system settings (any change I tried making immediately reverted back to the default).
Both times, I also had another issue: the system felt very sluggish.
Ultimately, I decided that, in the current state, systemd-home and its GDM integration are not for someone with my level/lack of expertise. I am grateful for the work people are putting into this (including the community help in this forum) and I am sure it will become more easily accessible in time. For now, I reverted to full disk encryption which I have been able to manage for a few years now.
Hello.
This way works because your systemd-homed selinux policy has been integrated into the main fedora-selinux policy?
BTW, I am curious, can’t the “forget key at suspend” feature be handled between logind and homed? Leaving the Login Manager to just be a “frontend” of whatever sort?
Atleast the “lockscreen” in the per-user context be opened before the forget-key phase, cd into some ${XDG_RUNTIME_DIR}/lockstate/whatever with all other required info copied, and then “forget-key” initiated?
Of course, the “backend” would have to be some systemd-locked maybe, or just a protocol, for this to be common…
Hi guys, I wanted to share my project Zena
https://zena-linux.github.io/
It uses systemd homed by default upon initial user creation.