I’ve just spent a couple of days on what seems to be a pretty deep hole in the btrbk-selinux documentation for Fedora. And being here, it might be found by others who encounter the same trap, and save them a couple of days.
The context: setting up btrbk backup between two F43 installations, close to stock standard, both using the standard Fedora 43 workstation structure with /home set up as btrfs. Wouldn’t work, the connection kept crashing (I was mainly examining journalctl on the server, which was not the World’s most informative). I probably should have checked the security logs instead. Anyway, I finally looked through the client logs more carefully:
lsetxattr rim/snap/opera/406 security.selinux=unconfined_u:object_r:snappy_home_t:s0 failed: Invalid argument
Huhhh? They’re both Fedora 43 systems, fully updated, so they should have the same selinux settings, right? - so I ignored it for a while. Oh, but snappy sounds like it might come with snapd? Oh, the dnf installation of snapd might add security contexts? Woww, that’s not obvious (well maybe it is to you, but not everyone’s so smart). I had only installed snapd a while ago so I could user opera once in a while, and had pretty much forgotten.
So now I have snapd (otherwise pointlessly) installed on the server, and it’s all working. I can’t find any mention anywhere of this trap, but it seems to me that it ought to be mentioned somewhere (well, to be honest, I’m not sure packages managed by dnf should be allowed to add security contexts, that seems a huge potential security black hole, but I guess other decisions have been made). Thank heavens I decided to use the Fedora machine as the server, so a fix was easy - I had initially considered using a Ubuntu server but decided it might not be able to handle the load. Phew!