unlockd sandbox: ProtectHome was the /run/user blocker, not the ro pass

Second live failure, same symptom: with ReadWritePaths=/run /run/user
loaded, the daemon's namespace still showed /run/user inaccessible.
Every ProtectHome variant covers /run/user in addition to /home and
/root — systemd overmounts it with an inaccessible directory, which both
explains the EACCES (0000-mode dir, not a read-only fs error) and why
the ReadWritePaths entry was shadowed. Drop ProtectHome; under
ProtectSystem=strict /home is read-only anyway, which is the protection
that matters for this daemon.

Co-Authored-By: Claude Fable 5 <[email protected]>

 cce-keyring-unlockd.service | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/cce-keyring-unlockd.service b/cce-keyring-unlockd.service
index 7ce1df0..52230f3 100644
--- a/cce-keyring-unlockd.service
+++ b/cce-keyring-unlockd.service
@@ -17,11 +17,14 @@ Environment=RUST_LOG=info
 NoNewPrivileges=yes
 CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_SYS_PTRACE
 ProtectSystem=strict
-# /run/user is its OWN tmpfs: ReadWritePaths=/run does not reach into the
-# submount, ProtectSystem=strict remounts it ro, and connect() to the user
-# bus socket then fails EACCES — which broke every unlock until listed here.
+# /run/user is listed explicitly: it is its own tmpfs, and the submount must
+# be exempt from the strict read-only pass for connect() to the user bus.
 ReadWritePaths=/run /run/user
-ProtectHome=yes
+# NO ProtectHome: every variant of it ALSO covers /run/user (systemd mounts
+# an inaccessible dir over it — EACCES on the bus socket broke every unlock,
+# and it shadows any ReadWritePaths entry). /home stays read-only via
+# ProtectSystem=strict, which is protection enough here.
+ProtectHome=no
 PrivateTmp=yes
 ProtectKernelTunables=yes
 ProtectKernelModules=yes