I’m following the Build on LXD guide but I get an error.
When I try to install LXD, specifically with this command sudo snap install lxd I get an error on Fedora 29:
error: cannot perform the following tasks:
- Start snap “lxd” (9664) services ([start snap.lxd.daemon.unix.socket] failed with exit status 1: Job for snap.lxd.daemon.unix.socket failed.
See “systemctl status snap.lxd.daemon.unix.socket” and “journalctl -xe” for details.
)
Anything in the journal that would suggest SELinux is blocking this? Can you check ausearch -m AVC perhaps?
I get:
Error opening config file (Permission denied)
NOTE - using built-in logs: /var/log/audit/audit.log
Error opening /var/log/audit/audit.log (Permission denied)
What does it mean?
Try running the command with superuser privileges
It could solve the problem, but why in the first place SELinux blocked it?
Are there any possible security problems if I execute it as root?
I checked this locally in Fedora cloud image:
Dec 12 07:31:17 localhost audit[3195]: AVC avc: denied { execute_no_trans } for pid=3195 comm="snap-confine" path="/usr/lib/snapd/snap-exec" dev="loop0" ino=6448 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
Dec 12 07:31:17 localhost audit[3195]: AVC avc: denied { map } for pid=3195 comm="snap-exec" path="/usr/lib/snapd/snap-exec" dev="loop0" ino=6448 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1
Dec 12 07:31:17 localhost audit[1]: AVC avc: denied { write } for pid=1 comm="systemd" name="lxd" dev="vda1" ino=149648 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:snappy_var_t:s0 tclass=dir permissive=0
Dec 12 07:31:17 localhost systemd[1]: Failed to create listening socket: Permission denied
Dec 12 07:31:17 localhost systemd[1]: snap.lxd.daemon.unix.socket: Failed to listen on sockets: Permission denied
Dec 12 07:31:17 localhost systemd[1]: snap.lxd.daemon.unix.socket: Failed with result 'resources'.
Dec 12 07:31:17 localhost systemd[1]: Failed to listen on Socket unix for snap application lxd.daemon.
Dec 12 07:31:18 localhost audit[2880]: AVC avc: denied { remove_name } for pid=2880 comm="snapd" name="lxc" dev="vda1" ino=149644 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=1
Dec 12 07:31:18 localhost audit[2880]: AVC avc: denied { unlink } for pid=2880 comm="snapd" name="lxc" dev="vda1" ino=149644 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=lnk_file permissive=1
So it’s SELinux as suspected, specifically this line:
denied { write } for pid=1 comm="systemd" name="lxd" dev="vda1" ino=149648
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:snappy_var_t:s0 tclass=dir
permissive=0
The systemd daemon, running with context system_u:system_r:init_t:s0, was denied a write operation on directory lxd, with context system_u:object_r:snappy_var_t:s0 (snappy_var_t is used for $SNAP_DATA under /var/snap/).
I’m working on some refactoring of snapd policy, hopefully this should go away once the changes land.
In the meantime, the fastest solution is probably switch to permissive mode.
A longer solution would be to enable permissive, install the snap, grab the denials and use audit2allow -R to generate a local policy to allow this specific action. Running sudo ausearch -m AVC -se system_u:object_r:snappy_var_t -ts <timestamp-from-journal> should list the relevant logs only. If you generate a local policy module, you woull need to remove it once the fixes land with a future version of snapd.
How do I switch to permissive mode? Could I change it back when you refactor snapd policy?
For the first question, I’ve found an answer on the RedHat docs
For the second question, is it going to be enough to set again enforced when you roll out the updated version?
sudo lxd init outputs
sudo: lxd: command not found
lxd init outputs
Error: Failed to connect to local LXD: Get http://unix.socket/1.0: dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
I suppose the permissions are a bit off, can you post the output of ls -l /var/snap/lxd/common/lxd/unix.socket?
The sudo lxd init error looks a bit fishy, needs futher investigation. Maybe Fedora 29 introduced some changes to sudo configuration too like they did with default umask.
That’s what I get:
srw-rw----. 1 root lxd 0 Dec 12 18:15 /var/snap/lxd/common/lxd/unix.socket
I confirm that I have lxd running on Fedora 29 after switching SELinux to permissive mode and adding myself to group lxd:
$ cat /etc/fedora-release
Fedora release 29 (Twenty Nine)
$ lxc launch ubuntu:16.04
Creating the container
Container name is: usable-muskrat
Starting usable-muskrat
Update: oh ok, it was not flawless: it seems that lxd.daemon is not stopping gracefully on system shutdown.
For those still running into this, a quick solution is:
Assuming my username is myuser
$ sudo setenforce 0 # Set SELinux to Permissive Mode
$ sudo snap install lxd # Install lxd
$ sudo ausearch -m avc -ts recent | audit2allow -M snap # Gather SELinux errors and create a custom 'snap' policy
$ sudo semodule -i snap.pp # Install the new snap policy
$ sudo setenforce 1 # Set SELinux back to Enforcing Mode
$ sudo usermod -aG lxd myuser # Add your user to the 'lxd' group
$ newgrp lxd # quick hack to reload your groups
$ newgrp myuser
$ lxd init # Start using lxdAfter 2 years, this is still the solution on Fedora 34. Thanks!
What are the SELinux denials that you see? The basic install of lxd snap and launch of a simple instance is part of a our CI which runs with enforcing mode and verifies that those actions do not trigger any new denials. Thus I’m wondering what is special about your setup? Perhaps the test needs to be improved and I’d be glad for any pointers on how that scenario is different from your use case. See https://github.com/snapcore/snapd/blob/master/tests/main/selinux-lxd/task.yaml#L37-L78 for reference
I tried to get all the journalctl messages, hope this helps
Jul 09 10:57:43 fedora sudo[105333]: carlo : TTY=pts/7 ; PWD=/home/carlo ; USER=root ; COMMAND=/usr/bin/snap install lxd
Jul 09 10:57:43 fedora sudo[105333]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Jul 09 10:57:43 fedora audit[105333]: USER_START pid=105333 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Jul 09 10:57:43 fedora snapd[105255]: api_snaps.go:299: Installing snap "lxd" revision unset
Jul 09 10:57:45 fedora snapd[105255]: store_download.go:482: Download size for https://api.snapcraft.io/api/v1/snaps/download/PMrrV4ml8uWuEUDBT8dSGnKUYbevVhc4_12398.snap: 33853440
Jul 09 10:57:48 fedora systemd[1]: Reloading.
...
Jul 09 10:57:48 fedora systemd[1]: Mounting Mount unit for snapd, revision 12398...
Jul 09 10:57:48 fedora kernel: loop0: detected capacity change from 0 to 66120
Jul 09 10:57:48 fedora systemd[1]: var-lib-docker-overlay2-882401f76e23c39536154db3c0b6ea6d9f2008bb36ef470e6cfa3a04d341e041-merged.mount: Deactivated successfully.
Jul 09 10:57:48 fedora systemd[1]: Mounted Mount unit for snapd, revision 12398.
...
Jul 09 10:58:20 fedora snapd[105255]: daemon.go:508: gracefully waiting for running hooks
Jul 09 10:58:20 fedora snapd[105255]: daemon.go:510: done waiting for running hooks
Jul 09 10:58:20 fedora systemd[1]: snapd.service: Deactivated successfully.
Jul 09 10:58:20 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=snapd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 09 10:58:20 fedora systemd[1]: snapd.service: Consumed 31.483s CPU time.
Jul 09 10:58:20 fedora systemd[1]: snapd.service: Scheduled restart job, restart counter is at 1.
Jul 09 10:58:20 fedora systemd[1]: Stopped Snap Daemon.
Jul 09 10:58:20 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=snapd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 09 10:58:20 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=snapd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 09 10:58:20 fedora systemd[1]: snapd.service: Consumed 31.483s CPU time.
Jul 09 10:58:20 fedora systemd[1]: Starting Snap Daemon...
Jul 09 10:58:20 fedora snapd[105775]: AppArmor status: apparmor not enabled
Jul 09 10:58:20 fedora snapd[105775]: patch.go:63: Patching system state level 6 to sublevel 1...
Jul 09 10:58:20 fedora snapd[105775]: patch.go:63: Patching system state level 6 to sublevel 2...
Jul 09 10:58:20 fedora snapd[105775]: patch.go:63: Patching system state level 6 to sublevel 3...
Jul 09 10:58:20 fedora snapd[105775]: daemon.go:248: started snapd/2.51-1.fc34 (series 16; classic; devmode) fedora/34 (amd64) linux/5.12.7-300.fc34.x86_64.
Jul 09 10:58:20 fedora kernel: loop1: detected capacity change from 0 to 8
Jul 09 10:58:20 fedora snapd[105775]: daemon.go:341: adjusting startup timeout by 35s (pessimistic estimate of 30s plus 5s per snap)
Jul 09 10:58:20 fedora systemd[1]: Started Snap Daemon.
Jul 09 10:58:20 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=snapd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 09 10:58:21 fedora snapd[105775]: store_download.go:482: Download size for https://api.snapcraft.io/api/v1/snaps/download/DLqre5XGLbDqg9jPtiAhRRjDuPVa5X1q_1026.snap: 64729088
Jul 09 10:58:27 fedora systemd[1]: Reloading.
...
Jul 09 10:58:29 fedora snapd[105775]: store_download.go:482: Download size for https://api.snapcraft.io/api/v1/snaps/download/J60k4JY0HppjwOjW8dZdYc8obXKxujRu_20948.snap: 71303168
...
Jul 09 10:58:35 fedora systemd[1]: Mounting Mount unit for lxd, revision 20948...
Jul 09 10:58:35 fedora kernel: loop2: detected capacity change from 0 to 139264
Jul 09 10:58:35 fedora systemd[1]: Mounted Mount unit for lxd, revision 20948.
Jul 09 10:58:35 fedora systemd[1]: Reloading.
...
Jul 09 10:58:36 fedora audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=n/a uid=0 gid=0 cmdline="snap run --hook install -r unset lxd" scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system permissive=1
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Jul 09 10:58:36 fedora audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=n/a uid=0 gid=0 path="/run/systemd/transient/snap.lxd.hook.install.4b834156-146c-4a88-9f19-392ec6927542.scope" cmdline="snap run --hook install -r unset lxd" scontext=system_u:system_r:snappy_cli_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=service permissive=1
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Jul 09 10:58:36 fedora systemd[1]: Started snap.lxd.hook.install.4b834156-146c-4a88-9f19-392ec6927542.scope.
Jul 09 10:58:36 fedora systemd[1]: snap.lxd.hook.install.4b834156-146c-4a88-9f19-392ec6927542.scope: Deactivated successfully.
...
Jul 09 10:58:37 fedora audit[1]: AVC avc: denied { create } for pid=1 comm="systemd" name="unix.socket" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file permissive=0
Jul 09 10:58:37 fedora systemd[1]: snap.lxd.daemon.unix.socket: Failed to create listening socket (/var/snap/lxd/common/lxd/unix.socket): Permission denied
Jul 09 10:58:37 fedora systemd[1]: snap.lxd.daemon.unix.socket: Failed to listen on sockets: Permission denied
Jul 09 10:58:37 fedora systemd[1]: snap.lxd.daemon.unix.socket: Failed with result 'resources'.
Jul 09 10:58:37 fedora systemd[1]: Failed to listen on Socket unix for snap application lxd.daemon.
Jul 09 10:58:37 fedora systemd[1]: Cannot find unit for notify message of PID 106362, ignoring.
...
Jul 09 10:58:38 fedora snapd[105775]: taskrunner.go:271: [change 2 "Start snap \"lxd\" (20948) services" task] failed: [start snap.lxd.daemon.unix.socket] failed with exit status 1: Job failed. See "journalctl -xe" for details.
...
Jul 09 10:58:41 fedora audit[105775]: AVC avc: denied { read } for pid=105775 comm="snapd" name=".directory" dev="sda5" ino=12 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=lnk_file permissive=1
Jul 09 10:58:41 fedora audit[105775]: AVC avc: denied { getattr } for pid=105775 comm="snapd" path="/home/carlo" dev="sda5" ino=12582913 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
Jul 09 10:58:41 fedora audit[105775]: AVC avc: denied { read } for pid=105775 comm="snapd" name="carlo" dev="sda5" ino=12582913 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
Jul 09 10:58:41 fedora audit[105775]: AVC avc: denied { open } for pid=105775 comm="snapd" path="/home/carlo" dev="sda5" ino=12582913 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
Jul 09 10:58:41 fedora systemd[1]: Unmounting Mount unit for lxd, revision 20948...
Jul 09 10:58:41 fedora umount[106586]: umount: /var/lib/snapd/snap/lxd/20948: not mounted.
Jul 09 10:58:41 fedora systemd[1]: run-snapd-ns-lxd.mnt.mount: Deactivated successfully.
Jul 09 10:58:41 fedora systemd[1]: var-lib-snapd-snap-lxd-20948.mount: Mount process exited, code=exited, status=32/n/a
Jul 09 10:58:41 fedora systemd[1]: var-lib-snapd-snap-lxd-20948.mount: Failed with result 'exit-code'.
Jul 09 10:58:41 fedora systemd[1]: Unmounted Mount unit for lxd, revision 20948.
Jul 09 10:58:41 fedora audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { stop } for auid=n/a uid=0 gid=0 cmdline="" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system permissive=1
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Jul 09 10:58:41 fedora audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=n/a uid=0 gid=0 cmdline="" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system permissive=1
exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
...
Jul 09 10:58:43 fedora snapd[105775]: handlers.go:511: Reported install problem for "lxd" as dca80c26-e093-11eb-9eeb-fa163ee63de6 OOPSID
Jul 09 10:58:43 fedora audit[105775]: AVC avc: denied { read } for pid=105775 comm="snapd" name=".directory" dev="sda5" ino=12 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=lnk_file permissive=1
Jul 09 10:58:43 fedora audit[105775]: AVC avc: denied { getattr } for pid=105775 comm="snapd" path="/home/carlo" dev="sda5" ino=12582913 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
Jul 09 10:58:43 fedora audit[105775]: AVC avc: denied { read } for pid=105775 comm="snapd" name="carlo" dev="sda5" ino=12582913 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
Jul 09 10:58:43 fedora audit[105775]: AVC avc: denied { open } for pid=105775 comm="snapd" path="/home/carlo" dev="sda5" ino=12582913 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1
Jul 09 10:58:43 fedora sudo[105333]: pam_unix(sudo:session): session closed for user root
Jul 09 10:58:43 fedora audit[105333]: USER_END pid=105333 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Jul 09 10:58:43 fedora audit[105333]: CRED_DISP pid=105333 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Jul 09 10:59:05 fedora systemd[1678]: dbus-:1.2-org.gnome.Screenshot@0.service: Deactivated successfully.
Jul 09 10:59:05 fedora systemd[1678]: dbus-:1.2-org.gnome.Screenshot@0.service: Consumed 1.848s CPU time.
Jul 09 11:00:52 fedora audit[107187]: USER_ACCT pid=107187 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="carlo" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
Jul 09 11:00:52 fedora audit[107187]: USER_CMD pid=107187 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/home/carlo" cmd=736E617020696E7374616C6C206C7864 exe="/usr/bin/sudo" terminal=pts/7 res=success'
Jul 09 11:00:52 fedora audit[107187]: CRED_REFR pid=107187 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/7 res=success'
I got curious too and did a fresh install on my F34 box:
$ sudo dnf install snapd
$ sudo snap install lxd
.. add user to 'lxd' group ..
$ lxd init --auto
Which produced the following SELinux errors (Note I had SELinux running in permissive mode):
$ sudo ausearch -m avc -ts recent
----
time->Fri Jul 9 14:23:20 2021
type=AVC msg=audit(1625855000.594:7501): avc: denied { mount } for pid=651396 comm="snap-confine" name="/" dev="tmpfs" ino=1 scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=1
----
time->Fri Jul 9 14:23:20 2021
type=AVC msg=audit(1625855000.641:7502): avc: denied { write } for pid=651396 comm="snap-confine" name="/" dev="tmpfs" ino=1 scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=1
----
time->Fri Jul 9 14:23:20 2021
type=AVC msg=audit(1625855000.641:7503): avc: denied { add_name } for pid=651396 comm="snap-confine" name="libEGL.so" scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=1
----
time->Fri Jul 9 14:23:20 2021
type=AVC msg=audit(1625855000.641:7504): avc: denied { create } for pid=651396 comm="snap-confine" name="libEGL.so" scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=lnk_file permissive=1
----
time->Fri Jul 9 14:23:20 2021
type=AVC msg=audit(1625855000.642:7505): avc: denied { read } for pid=651396 comm="snap-confine" name="/" dev="tmpfs" ino=1 scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=1
----
time->Fri Jul 9 14:23:20 2021
type=AVC msg=audit(1625855000.642:7506): avc: denied { create } for pid=651396 comm="snap-confine" name="vdpau" scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=1
----
time->Fri Jul 9 14:23:20 2021
type=AVC msg=audit(1625855000.670:7507): avc: denied { remount } for pid=651396 comm="snap-confine" scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=1
----
time->Fri Jul 9 14:23:21 2021
type=AVC msg=audit(1625855001.205:7564): avc: denied { create } for pid=1 comm="systemd" name="unix.socket" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file permissive=1
----
time->Fri Jul 9 14:23:21 2021
type=AVC msg=audit(1625855001.205:7565): avc: denied { write } for pid=1 comm="systemd" name="unix.socket" dev="nvme1n1p4" ino=4266651 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=sock_file permissive=1
Can you fix the labeling in your home? AFAIK those should have a label user_home_t, and there are policy rules that allow snapd access to such files and directories. You can run restorecon -F -R -v /home/carlo.
This is something that systemd upstream has tried to fix a couple of times already, but AFAIK it still does not work properly. IOW systemd should observe when the policy changes and reload its cache. You can run systemctl daemon-reexec for workaround that. I think the last PR related to this is https://github.com/systemd/systemd/pull/19551.
Are you using the nvidia proprietary driver and corresponding libraries?