Building a new home with systemd-homed on fedora

nfs can. At my last job, we setup DRBD to host all the server home directories over NFS with autos. Login happened via sssd and then their user specific home directory was mounted on login. The files didn’t exist on the server until the user logged in and could be mounted on multiple systems at once (NFS is also one of the few ways to do RWX volumes in Kubernetes).

With a regular nfs, if someone has access to the nfs server, they can access all the home directories, but doing it through DRBD adds another layer to that since DRBD is also managing the block devices underneath. (It appears Cisco has a doc on doing DRBD with LUKS in OpenStack.)

Oh, yes, definitely — I’ve worked in environments with large-scale centralized NFS home directories. I meant the other systemd-homed mechanics.

1 Like

Ah, yeah - I think my trouble with initially understanding the point of this is that I’m coming from that world for these concepts and was trying to see how systemd-homed fit into that world instead of starting from a place of a regular user wanting portability/privacy with their own data. I think the scope and practical use cases of it are starting to make more sense to me now. Many thanks!

1 Like

I think these warnings are due to current container-selinux and selinux-policy-devel packages being out of sync, and shouldn’t affect this. Possibly worth tracking down and filing a bug in one of those packages, though.

1 Like

@richiedaze Thanks for this very nice guide. I think it might be helpful to have a “what this step does” explanation for each step (maybe using the drop-down markup that Sampson uses in his message, so it doesn’t become too cluttered for people who just want the recipe).

And, in Step 8 — it isn’t obvious to me that secure_home is the username to be created. That probably should be spelled out.

1 Like

Assuming a predictable mount location for these home mounts, could this be handled with semanage fcontext -a -t user_home_dir_t /path/to/homed/mounts/[^/]+ ? If so, it would make step 8 cleaner.

Similarly, this could be defined in /etc/systemd/homed.conf so the individual mount command is cleaner. It looks like the default shipped in Fedora is already btrfs (commented out in the conf), so this arg might be redundant.

1 Like

I will edit the guide to make it clearer.

I posted this here to generally get ideas and different points of views on how to use systemd-homed on fedora. You and @vwbusguy have helped tremendously by giving us your point of views on networking aspects of this project.

I have written a SELinux policy for this project. I have to rewrite the policy every time to adjust to the users preferences. I would like to add rules for networking homes with homed. From your guys conversation, I would assume homed is a network client only or is it a network server as well?

Hopefully everyone with similar interest for this project will come here for a better understanding and use case for this project . My intent is to build a fedora wiki on this subject, but still lack information on different use cases and troubles that arise in these cases. An example below:

So in this case, new homes created by homed (or any mk.fs), selinux labels them “unlabeled_t”. So I adjusted my policy to include rules for home directories with proper labels and home directories without. I have searched and read that you have to manually label new filesystems on (RH,Fedora,etc). For this reason, policies for homed have been abandoned. SELinux ref also states that it’s incomplete because of the labeling issue.

By adding this rule to the policy
and adding
–luks-extra-mount-options=defcontext=system_u:object_r:user_home_dir_t:s0 flag to the build command, would properly label it correctly on a default LUKS btrfs filesystem.

Using –luks-extra-mount-options=defcontext=system_u:object_r:user_home_dir_t:s0 homed build flag does not properly label other LUKS file types (ext4,xfs). It labels them user_home_t , which would still need a home directory relabeling, thus needing an another solution, hence why I added –fs-type=btrfs flag to the build command on step 8.

WIthout the –luks-extra-mount-options=defcontext=system_u:object_r:user_home_dir_t:s0 build flag, the administrator or logged in user must manually relabel the home directory with restorecon or an equivalent command. So in theory, step 8 saves you from manually relabeling your home.


Thanks for the context - I’m surprised systemd-homed doesn’t set that by default. That seems like a lot to commit to muscle memory.

1 Like

How does this work on a mail server, where the Maildir is in the user’s home directory?

The LDA moves/transports the message to the user’s home dir. If the dir was not accessible to the LDA process (in my case dovecot’s LDA), how would this work?

“Poorly”, I’d say. If you would want to use this in a situation like that, you’d need to deliver mail to somewhere else.


@richiedaze , just tested your custom homed policy and it works with SELinux set to enforcing. Could you look in one more case with homed - there is possibility to use FIDO2 keys (e.g., Yubikey 5 ) when creating new user. Normal login using Yubikey is fine, no SELinux alerts. But after sleep/lock logging in with Yubikey gives this alert:


SELinux is preventing systemd-homewor from lock access on the chr_file /dev/hidraw1.

***** Plugin catchall (100. confidence) suggests **************************

If you believe that systemd-homewor should be allowed lock access on the hidraw1 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:

ausearch -c ‘systemd-homewor’ --raw | audit2allow -M my-systemdhomewor

semodule -X 300 -i my-systemdhomewor.pp

Additional Information:
Source Context system_u:system_r:systemd_homework_t:s0
Target Context system_u:object_r:usb_device_t:s0
Target Objects /dev/hidraw1 [ chr_file ]
Source systemd-homewor
Source Path systemd-homewor
Host mbp-fedora
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-37.18-1.fc37.noarch
Local Policy RPM
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name mbp-fedora
Platform Linux mbp-fedora 6.1.7-200.fc37.x86_64 #1 SMP
PREEMPT_DYNAMIC Wed Jan 18 17:11:49 UTC 2023
x86_64 x86_64
Alert Count 2
First Seen 2023-01-31 08:50:32 EET
Last Seen 2023-01-31 09:07:07 EET
Local ID b04cdf60-6e53-443a-a751-845dba59b930

Raw Audit Messages
type=AVC msg=audit(1675148827.911:533): avc: denied { lock } for pid=6937 comm=“systemd-homewor” path=“/dev/hidraw1” dev=“devtmpfs” ino=184 scontext=system_u:system_r:systemd_homework_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file permissive=1

Hash: systemd-homewor,systemd_homework_t,usb_device_t,chr_file,lock

Would it be possible to update your custom policy by adding this case ?

1 Like

So basically this is rather for workstation systems or servers which do not have any services access the home dir.

Yes, that seems fair.

1 Like

If I remember correctly, systemd-homed uses an encrypted BTRFS subvolume. Each users home is it’s own subvolume. With a LUKS encrypted /home file system, once it’s unlocked, anyone with sudo access can see others users home directories. Let me give you an example:

My partner and I share a computer running Fedora with systemd-homed configured. I have my home on a USB drive, so I plug it into the computer and when I log in it unlocks the subvolume and mounts the USB drive. My partners home directory is on the internal drive. When I sudo to root, I still can’t see their home or files. There’s just an encrypted subvolume assigned to them.

It depends on a) defaults and b) your choices when homed user is created. I choose LUKS with EXT4 “inside”.

1 Like

The recipe above gives you a btrfs filesystem on a LUKS (in a file).

1 Like

Shouldn’t the server wait until the user logs in before delivering the mail?

That’s not how an LDA works.

Yeah. I mean, I suppose they could? It’s probably just as easy to move to delivering under /var/mail or /srv/mail or something. I can see the general appeal of a blanket rule of “system daemons don’t mess with contents of users’ homes”. On the other hand, there’s crond — of course actually a system daemon, but it also runs user jobs, and the user doesn’t need to be logged in for that, and to me at least it doesn’t feel quite as invasive as a mail delivery agent dropping files somewhere.

For cases where that’s desired, I think this model just doesn’t work. Although one adaptation might be to use an overlay filesystem of some sort. I can think of several ways to do that: files could be dropped in place and then “absorbed” when the user logs in; or, there could be clearly-defined (per-system, of course) subdirectories which would be unencrypted…