Building a new home with systemd-homed on fedora

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…

I am well aware that I can deliver mails to another dir but the home dir. It is in fact the prerequisite for virtual users.

But, users usually have scripts in their home dir e.g. ~/bin, they can’t just write to persistent storage outside their home (unless setup separately). Thus cron jobs are a bust, and there are also other services that might need access. I am not saying that this isn’t possible, but rather just a hassle I’d like to avoid.

Well, again, it seems like this is probably not what you want for those cases.

Their scripts can read from outside the home directory when the user is logged in.
Potentially the mail could be in /var/spool/mail and when the user logs in the script could retrieve the mail for them.

Indeed, this is true. It’s also true for autofs as well. It’s also true for script environments that live in the user’s home folder. It’s important and useful to grok the limitations of such things and if it doesn’t fit your use case, then maybe systemd-homed isn’t the right fit for that environment or you might need to use an alternative path for those scripts to love.

I use scripts and systemd user services to manage my portable home directory.

  • I use timers as a substitute for cron processes
  • I use paths to monitor files and/or directories for creation, deletion or modifications.
  • I use services to start and stop my podman containers
  • I install my flatpaks from flathub in user mode

You should be able to accomplish normal user interactions when you are mounted, logged in and have the correct label context for the home directory. When the user’s and system’s Group permissions match, those permissions are also available.

Hi all

I tried on rawhide(f39) and encountered one failure like this:

make -f /usr/share/selinux/devel/Makefile homed.pp
Compiling targeted homed module
homed.te:151:ERROR ‘syntax error’ at token ‘container_runtime_read_tmpfs_files’ on line 7898:
#line 151
/usr/bin/checkmodule: error(s) encountered while parsing configuration
make: *** [/usr/share/selinux/devel/include/Makefile:157: tmp/homed.mod] Error 1

Do you know how can I fix this problem? Or do I need to change to f37/f38 or change to a stable version of homed-selinux?