I’ve got a few daemons/services running - they’re “systemd --user” services (e.g. in ~/.config/systemd/user.
These have permissions to files in my home directory, but it seems that they can’t do some things that I can do when ssh’d in to that account on the box… In particular, one of the daemons uses a mariadb/mysql connector to talk to a locally running mariadb server (via the domain socket connection - /var/lib/mysql/mysql.sock) If I run the daemon via an ssh session, manually, everything works, with SELINUX in enforcing mode. But it doesn’t work when it’s started by systemd at boot time as a user service.
The issue smelled like an SELINUX issue, so I temporarily disabled it, rebooted, and my daemon magically started working again. I put SEL in permissive mode and then used sealert to help generate some SEL rules automatically to allow stuff (approx: sealert -a /var/log/audit/audit.log; … ausearch -c ‘mydaemon’ --raw | audit2allow -M my-mydaemon )
Now, my software works (and I can connect to mysql) with SEL either off or in permissive mode. But it doesn’t work in enforcing mode. In both permissive and enforcing mode I see no warnings or issues in audit.log. I wonder if my systemd --user daemons don’t have permission to write to the audit log so I’m not seeing some error I should in permissive mode.
I’m no expert in either systemd, or SEL- I’m not sure what I can/should do to further diagnose the issue, and I’d really rather not tur off SEL.
Either I need to see what kind of errors systemd would be wiriting to the journal if my user-level services COULD write to it, or maybe there is some other way I could get information out of SEL somehow.
How are people normally writing daemons that the run from their useraccount (systemd --user) that need to access anything outside files in the local account? What is the expected or recommended process?